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Executive Summary 

■ It is difficult to overstate the importance of the internet to modern business and to society in 
general. The internet is essential to the exchange of all manner of information, including 
transactional data, marketing and advertising information, remote access to services, 
entertainment, and much more. 

■ The internet is not a single network, but rather a complex grid of independent interconnected 
networks. The design of the internet is based on a trust relationship between these 
networks and relies on a protocol known as the Border Gateway Protocol (BGP) to route traffic 
among the various networks worldwide. BGP is the protocol that internet service providers 
(ISPs) and enterprises use to exchange route information between them. 

■ Unfortunately, BGP was not designed with security in mind. Traffic typically traverses multiple 
networks to get from its source to its destination. Networks implicitly trust the BGP information 
that they receive from each other, making BGP vulnerable to route hijacks. 

■ A route hijack attack can deny access to internet services, misdeliver traffic to malicious 
endpoints, and cause routing instability. A technique known as BGP route origin validation (ROV) 
is designed to protect against route hijacking. 

■ The National Cybersecurity Center of Excellence (NCCoE) at the National Institute of Standards 
and Technology (NIST) has developed proof-of-concept demonstrations of BGP ROV 
implementation designed to improve the security of the internet's routing infrastructure. 

■ This NIST Cybersecurity Practice Guide demonstrates how networks can protect BGP routes 
from vulnerability to route hijacks by using available security protocols, products, and tools to 
perform BGP ROV to reduce route hijacking threats. The example implementation described in 
this guide aims to protect the integrity and improve the resiliency of internet traffic exchange by 
verifying the source of the route. 

CHALLENGE 

Most of the routing infrastructure underpinning the internet currently lacks basic security services. In 
most cases, internet traffic must transit multiple networks before reaching its destination. Each network 
implicitly trusts other networks to provide (via BGP) the accurate information necessary to correctly 
route traffic across the internet. When that information is inaccurate, traffic will take inefficient paths 
through the internet, arrive at malicious sites that masquerade as legitimate destinations, or never 
arrive at its intended destination. These impacts can be mitigated through a widespread adoption 
of BGP ROV. 

To date, ISPs and enterprises have been slow to adopt BGP ROV for reasons that include an 
unavailability of detailed BGP ROV deployment, operation, and management guidelines, as well as 
lingering concerns and questions about functionality, performance, availability, scalability, and policy 
implications. These concerns need to be addressed so that potential users of BGP ROV can appreciate 
the feasibility of using BGP ROV and the increased security that it can provide. 
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SOLUTION 

The NCCoE Secure Inter-Domain Routing (SIDR) Project is improving internet security by demonstrating 
howto use ROV to protect against route hijacks. The SIDR Project has produced a proof-of-concept 
example that demonstrates the use of BGP ROV in realistic deployment scenarios, has developed 
detailed deployment guidance, has addressed implementation and use issues, and has generated best 
practices and lessons learned. Project results are presented in this publicly available NIST Cybersecurity 
Practice Guide. This guide describes the following concepts: 

■ security objectives that are supported by implementing BGP ROV that uses Resource Public Key 
Infrastructure (RPKI) mechanisms 

■ an example solution of methods and tools that demonstrate and enable a practical 
implementation of BGP ROV 

■ how to protect your own internet addresses from route hijacking by registering them with 
trusted sources, thereby gaining assurance that traffic intended for your organization will not be 
hijacked when it is forwarded by entities that perform BGP ROV 

■ how to perform BGP ROV on received BGP route updates to validate, if possible, whether the 
entity that originated the route is in fact authorized to do so 

■ how to more precisely express your routing security requirements and/or service offerings 

While the NCCoE used a suite of available products to address this challenge, this guide does not 
endorse these particular products, nor does it guarantee compliance with any regulatory initiatives. Your 
organization's information security experts should identify the products that will best integrate with 
your existing tools and information technology (IT) system infrastructure. Your organization can adopt 
this solution or one that adheres to these guidelines in whole, or you can use this guide as a starting 
point for tailoring and implementing parts of a solution. 


61 BENEFITS 

62 The NCCoE's practice guide is intended to improve the security and stability of the global internet by 

63 allowing networks to verify the validity of BGP routing information and strengthen the security and 

64 stability of traffic flowing across the global internet—benefitting all organizations and individuals that 

65 use and rely on it. This practice guide can help your organization: 

66 ■ reduce the number of internet outages due to BGP route hijacks 

67 ■ ensure that internet traffic reaches its destination 

68 ■ make informed decisions regarding routes and what actions to take in cases when BGP ROV 

69 implementation has not been performed or has indicated that an advertised route is invalid 

70 SHARE YOUR FEEDBACK 

71 You can view or download the guide at https://nccoe.nist.gov/proiects/building-blocks/secure-inter- 

72 domain-routing . Help the NCCoE make this guide better by sharing your thoughts with us as you read 

73 the guide. If you adopt this solution for your own organization, please share your experience and advice 

74 with us. We recognize that technical solutions alone will not fully enable the benefits of our solution, so 
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we encourage organizations to share lessons learned and best practices for transforming the 
processes associated with implementing this guide. 

To provide comments or to learn more by arranging a demonstration of this example 
implementation, contact the NCCoE at sidr-nccoe(S)nist.gov . 


TECHNOLOGY PARTNERS/COLLABORATORS 


Organizations participating in this project submitted their capabilities in response to an open call in the 
Federal Register for all sources of relevant security capabilities from academia and industry (vendors 
and integrators). The following respondents with relevant capabilities or product components (identified 
as "Technology Partners/Collaborators" herein) signed a Cooperative Research and Development 
Agreement (CRADA) to collaborate with NIST in a consortium to build this example solution. 


AT&T 


CenturyLink 


• 11111111 

CISCO COMCAST 


jumper 


THE GEORGE 
WASHINGTON 
UNIVERSITY 
WASHINGTON. DC 


Certain commercial entities, equipment, products, or materials may be identified by name or company 
logo or other insignia in order to acknowledge their participation in this collaboration or to describe an 
experimental procedure or concept adequately. Such identification is not intended to imply special 
status or relationship with NIST or recommendation or endorsement by NIST or NCCoE; neither is it 
intended to imply that the entities, equipment, products, or materials are necessarily the best available 
for the purpose. 


The National Cybersecurity Center of Excellence (NCCoE), a part of the 
National Institute of Standards and Technology (NIST), is a collaborative 
hub where industry organizations, government agencies, and academic 
institutions work together to address businesses' most pressing 
cybersecurity challenges. Through this collaboration, the NCCoE develops 
modular, easily adaptable example cybersecurity solutions 
demonstrating how to apply standards and best practices using 
commercially available technology. 


LEARN MORE 

Visit https://www.nccoe.nist.gov 
nccoe(5)nist.gov 

301 - 975-0200 
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NATIONAL CYBERSECURITY CENTER OF EXCELLENCE 

The National Cybersecurity Center of Excellence (NCCoE), a part of the National Institute of Standards 
and Technology (NIST), is a collaborative hub where industry organizations, government agencies, and 
academic institutions work together to address businesses' most pressing cybersecurity issues. This 
public-private partnership enables the creation of practical cybersecurity solutions for specific 
industries, as well as for broad, cross-sector technology challenges. Through consortia under 
Cooperative Research and Development Agreements (CRADAs), including technology partners—from 
Fortune 50 market leaders to smaller companies specializing in IT security—the NCCoE applies standards 
and best practices to develop modular, easily adaptable example cybersecurity solutions using 
commercially available technology. The NCCoE documents these example solutions in the NIST Special 
Publication 1800 series, which maps capabilities to the NIST Cybersecurity Framework and details the 
steps needed for another entity to recreate the example solution. The NCCoE was established in 2012 by 
NIST in partnership with the State of Maryland and Montgomery County, Md. 

To learn more about the NCCoE, visit https://www.nccoe.nist.gov/ . To learn more about NIST, visit 
https://www.nist.gov . 

NIST CYBERSECURITY PRACTICE GUIDES 

NIST Cybersecurity Practice Guides (Special Publication Series 1800) target specific cybersecurity 
challenges in the public and private sectors. They are practical, user-friendly guides that facilitate the 
adoption of standards-based approaches to cybersecurity. They show members of the information 
security community how to implement example solutions that help them align more easily with relevant 
standards and best practices, and provide users with the materials lists, configuration files, and other 
information they need to implement a similar approach. 

The documents in this series describe example implementations of cybersecurity practices that 
businesses and other organizations may voluntarily adopt. These documents do not describe regulations 
or mandatory practices, nor do they carry statutory authority. 

ABSTRACT 

The Border Gateway Protocol (BGP) is the default routing protocol to route traffic among internet 
domains. While BGP performs adequately in identifying viable paths that reflect local routing policies 
and preferences to destinations, the lack of built-in security allows the protocol to be exploited by route 
hijacking. Route hijacking occurs when an entity accidentally or maliciously alters an intended route. 

Such attacks can (1) deny access to internet services, (2) detour internet traffic to permit eavesdropping 
and to facilitate on-path attacks on end points (sites), (3) misdeliver internet network traffic to malicious 
end points, (4) undermine internet protocol (IP) address-based reputation and filtering systems, and 
(5) cause routing instability in the internet. This document describes a security platform that 
demonstrates how to improve the security of inter-domain routing traffic exchange. The platform 
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provides route origin validation (ROV) by using the Resource Public Key Infrastructure (RPKI) in a manner 
that mitigates some misconfigurations and malicious attacks associated with route hijacking. The 
example solutions and architectures presented here are based upon standards-based, open-source, and 
commercially available products. 

KEYWORDS 

AS, autonomous systems, BGP, Border Gateway Protocol, DDoS, denial-of-service (DoS) attacks, internet 
service provider, ISP, Regional Internet Registry, Resource Public Key Infrastructure, RIR, ROA, route 
hijack, route origin authorization, route origin validation, routing domain, ROV, RPKI 
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1 Summary 

This National Institute of Standards and Technology (NIST) Cybersecurity Practice Guide addresses the 
challenge of using existing protocols to improve the security of inter-domain routing traffic exchange in 
a manner that mitigates accidental and malicious attacks associated with route hijacking. 

As described in NIST Special Publication (SP) 800-189 (draft), a route prefix hijack occurs when an 
autonomous system (AS) accidentally or maliciously originates a Border Gateway Protocol (BGP) update 
for a route prefix that it is not authorized to originate. For example, a BGP update for internet protocol 
(IP) prefix 192.0.2.0/24 might legitimately be originated by one AS, but a different AS might fraudulently 
originate a BGP route update for that prefix. Many ASes for which the illegitimate AS is closer (i.e., in 
terms of a shorter routing path length) would trust the false update, and thus data traffic from them 
toward the said prefix would be misrouted to the illegitimate AS. The path to the prefix via the false 
origin AS will be shorter on average for about half of all ASes in the internet. So, nearly half of the 
internet ASes would install the false route in their Forwarding Information Base (FIB). 

When an offending AS fraudulently announces a more specific prefix than the prefix announced 
legitimately by another AS, practically all of the internet ASes would install the false route in their FIB. 

This Practice Guide implements and follows various Internet Engineering Task Force (IETF) Request for 
Comments (RFC) documents that define Resource Public Key Infrastructure (RPKI)-based BGP route 
origin validation (ROV), such as RFC 6480, RFC 6482, RFC 6811, and RFC 7115, as well as 
recommendations of NIST SP 800-54, Border Gateway Security. To the extent practicable from a system 
composition point of view, the security platform design, build, and test processes have followed NIST 
SP 800-160, Systems Security Engineering: Considerations for a Multidisciplinary Approach in the 
Engineering of Trustworthy Secure Systems. 

The NIST SP 1800-14 series of documents consists of the following volumes: 

■ Volume A: an executive-level summary describing the challenge that RPKI-based ROV is 
designed to address, the ROV solution, and its benefits 

■ Volume B: a rationale for, and descriptions of, RPKI-based internet routing platforms that 
perform BGP-based ROV 

■ Volume C: a series of Flow-To Guides, including instructions for the installation and 
configuration of the necessary services, that show system administrators and security engineers 
how to achieve similar outcomes 

The solutions and architectures presented are built upon standards-based, commercially available, and 
open-source products. These solutions can be used by any organization providing or using internet 
routing services that is willing to perform the steps necessary to perform and/or benefit from RPKI- 
based ROV. Interoperable solutions are provided that are available from different types of sources (e.g., 
both commercial and open-source products). 
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This summary section ( Section 1 ) describes the challenge addressed by Volume B (Approach, 
Architecture, and Security Characteristics), the solution demonstrated to address the challenge, and the 
benefits of the demonstrated solution. Section 2, How to Use This Guide, explains how each volume of 
this guide may be used by business decision makers, program managers, and information technology 
(IT) professionals, such as systems administrators. Section 3, Background, provides a high-level project 
overview. Section 4, Approach, provides a more detailed treatment of the project's intended audience, 
scope, assumptions, and the risks that informed it. It also describes the technologies and components 
that were provided by industry collaborators to enable platform development, and lists the 
Cybersecurity Framework functions supported by each collaborator-contributed component. For each 
security characteristic supported, it lists not only the Cybersecurity Framework categories and 
subcategories, but also the Security and Privacy Controls for Information Systems and Organizations 
[NIST SP 800-53] controls and additional references, standards, and guidelines that apply to each 
security function being demonstrated. Section 5, Architecture, describes the RPKI-based ROV reference 
architecture and the usage scenarios that it supports, as well as the architecture of the laboratory-based 
solution that was implemented at the National Cybersecurity Center of Excellence (NCCoE). Section 6, 
Outcome, discusses lessons learned, best practices, and other items relevant to systems administrators' 
experiences with respect to integrating the new capabilities into their systems and in systems 
operations and maintenance. Section 7, Functional and Robustness Results, summarizes the tests that 
were performed to demonstrate security platform functionality and provides an overview of platform 
performance in the scenarios demonstrated. 

Section 8, Recommendations for Follow-on Activities, is a brief description of future work that could be 
pursued to promote the adoption of Border Gateway Protocol Security (BGPsec) [RFC 8205] to provide 
protection for the path information in BGP updates. Appendices are provided for a description of the 
use of NIST SP 800-160 in project design and development; recommended education and training 
requirements for internet service provider (ISP) operators and enterprises; further discussion of the 
mapping of the secure inter-domain routing (SIDR) security platform to the Cybersecurity Framework 
Core-, informative security references cited in the Cybersecurity Framework Core; further discussion of 
assumptions; functional test requirements; results; acronyms; and references. 

1.1 Challenge 

Attacks against the internet routing functions are probably the greatest current threat to today's 
internet. Routing attacks can have regional, or even global, impact. There have been numerous incidents 
in recent years involving control plane anomalies, such as route hijacking, AS path modification attacks 
(e.g., an AS in the middle maliciously shortens a path to attract more traffic), route leaks, spoofing 
source addresses, etc., resulting in Denial-of-Service (DoS), unwanted data traffic detours, and 
performance degradation that is sufficiently severe to seriously disrupt the internet on a very large scale 
and for periods that can seriously harm organizations, the economy, and national security. Many of 
these types of attacks are described in detail in Secure Inter-Domain Traffic Exchange, NIST SP 800-189 
(draft). 
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Protocols have been defined that are designed to provide protection against many of the routing attacks 
mentioned above. The technique that is the subject of this Practice Guide, RPKI-based ROV, enables 
operators to verify that the AS that has originated a BGP route advertisement is in fact authorized to do 
so. Use of RPKI-based ROV can provide protection against accidental and some malicious route hijacks. A 
second protocol, BGPsec, allows network operators to verify the validity of the entire routing path 
across the internet (referred to as path validation). The use of RPKI-based ROV in conjunction with 
BGPsec can provide protection against malicious route hijacks as well as other routing attacks. 
Unfortunately, the adoption of both ROV and BGPsec is still very limited. In the case of BGPsec, while 
the specification of the BGPsec-based path validation is complete [RFC 8205], [RFC 8207], [RFC 8210], 
and open-source implementations [NIST BGP-SRx] [Parsons BGPsec] are available, there is still a lack of 
commercial implementations available from router vendors. 

BGPsec also has several other obstacles impeding its deployment, as compared with ROV, such as the 
fact that support for it will be resource-intensive because it increases the size and number of routing 
messages that are sent, and each message will require a cryptographic verification of at least one, and 
most likely multiple, digital signatures. Digital signature verification will be processing-intensive and may 
require hardware upgrades and/or software optimizations [NANOG69] [V Sriramj . It also adds a level of 
complexity with respect to the acquisition and management of public keys for BGP routers, as well as 
the X.509 certificates used in sharing those keys. 

Although the BGP path validation protections of BGPsec have not yet been incorporated into most 
vendor equipment, BGP ROV implementations, on the other hand, are more advanced. ROV capabilities 
have already been incorporated into the equipment of major vendors (i.e., they ship with Cisco, Juniper, 
and Alcatel/Lucent/Nokia routers). Further RPKI operations and repositories at all five Regional Internet 
Registries RIRs) are in production. In some regions of the world, RIRs provide tools and support that 
facilitate an efficient implementation of RPKI-based ROV. Flowever, commercial adoption to date has 
been slow, particularly in the North American region. This situation is beginning to change in other 
regions of the world. As of this writing, Europe, in particular, is approaching route origin authorization 
(ROA) coverage of approximately 33 percent of their announced IPv4 address space, due in part to 
forward-looking adoption policies and favorable and flexible usage polices for RPKI services. North 
America trails Europe, Latin and South America, and Africa in its rate of adoption, with only 
approximately three percent of its announced IPv4 address space covered by ROAs. 

1.2 Solution 

This Practice Guide (NIST SP 1800-14) describes how to use available security protocols, products, and 
tools to provide RPKI-based ROV. This Practice Guide focuses on a proof-of-concept implementation of 
the IETF security protocols and the NIST implementation guidance needed to protect ISPs and ASes 
against widespread and localized route hijacking attacks. Although it would have been preferable to 
protect against additional types of routing attacks by also focusing on the more comprehensive solution 
of BGP path validation in conjunction with ROV, the lack of commercial vendor implementation support 
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for BGPsec makes providing a BGP path validation solution impractical at this time. Hence, this Practice 
Guide is focusing only on providing ROV. 

The proof-of-concept implementation is used to demonstrate BGP ROV, using RPKI, to address and 
resolve route hijacking issues. The demonstration shows how, by using ROV, an AS can protect routes 
that it originates and flag and discard (or apply some other policy to, as desired) bogus routes that it 
receives that do not come from ASes that are authorized to originate the routes. The proof-of-concept 
implementation demonstrates RPKI-based ROV in realistic deployment scenarios. Also, some additional 
functionality, performance, robustness, and availability tests suggested by industry collaborators on the 
team were performed. 

This Practice Guide offers detailed deployment guidance, identifies implementation and use issues, and 
generates best practices and lessons learned. Volume C of this Practice Guide serves as a detailed 
implementation guide to the practical steps required to implement a cybersecurity reference design that 
addresses the inter-domain routing security challenge. 

1.3 Benefits 

The ROV capabilities demonstrated by the proof-of-concept implementation described in this Practice 
Guide improve inter-domain routing security by using standards-conformant security protocols to 
enable an entity that receives a BGP route update to validate whether the AS that has originated it is in 
fact authorized to do so. The capability demonstrated by the proof-of-concept can facilitate the 
adoption of ROV by autonomous systems by making it easier for entities to use the RPKI to create and 
validate objects that explicitly and verifiably assert that an AS is authorized to originate routes to a given 
set of prefixes. The creation of ROAs can be accomplished independently by each address resource 
holder, and ROV can be deployed by each AS independently. Thus, there is clearly benefit for early 
adopters, and deployment grows in a distributed manner. All organizations and individuals who are 
dependent on the internet stand to benefit greatly from the improvement to the security and stability of 
the global internet that can be achieved by providing a level of assurance that routing assertions come 
from the sources that are authorized to originate them. In particular, entities that issue ROA for the 
prefixes that they hold will benefit from the assurance that accidental hijackings and some malicious 
hijackings are prevented. 

2 How to Use This Guide 

This NIST Cybersecurity Practice Guide demonstrates a standards-based reference design and provides 
users with the information that they need to replicate this approach to inter-domain routing security. 
The reference design is modular and can be deployed in whole or in part. 
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This guide contains three volumes: 

■ NIST SP 1800-14A: Executive Summary 

■ NIST SP 1800-14B: Approach, Architecture, and Security Characteristics — what we built and why 
(you are here) 

■ NIST SP 1800-14C: How-To Guides — instructions for building the example solution 
Depending on your role in your organization, you might use this guide in different ways: 

Business decision makers, including chief security and technology officers, will be interested in the 
Executive Summary (NIST SP 1800-14A), which describes: 

■ The challenges that enterprises face in implementing and maintaining ROV 

■ An example solution built at the NCCoE 

■ The benefits of adopting the example solution 

Technology or security program managers who are concerned with how to identify, understand, assess, 
and mitigate risk will be interested in this part of the guide (NIST SP 1800-14B). NIST SP 1800-14B 
describes what we did and why. Section 4.4, Risk Assessment, will be of particular interest. This section 
provides a description of the risk analysis that we performed and maps the security services provided by 
this example solution to NIST's Framework for Improving Critical Infrastructure Cybersecurity and to 
relevant security standards and guidelines. 

You might share the Executive Summary, NIST SP 1800-14A, with your leadership team members to help 
them understand the importance of adopting standards-based ROV approaches to protect your 
organization's digital assets. 

IT professionals who want to implement an approach like this will find the whole Practice Guide useful. 
You can use the How-To portion of the guide, NIST SP 1800-14C, to replicate all or parts of the build that 
were created in our lab. The How-To guide provides specific installation, configuration, and integration 
instructions for implementing the example solution. We do not re-create the product manufacturers' 
documentation, which is generally widely available. Rather, we show how we incorporated the products 
together in our environment to create an example solution. 

This guide assumes that IT professionals have experience in implementing security products within 
enterprises. While we have used a suite of commercially available and open-source software products to 
address this challenge, this guide does not endorse these particular products. Your organization can 
adopt this solution or one that adheres to these guidelines in whole, or you can use this guide as a 
starting point for tailoring and implementing parts of a solution that would support the deployment of 
an ROV-RPKI system and the corresponding business processes. Your organization's security experts 
should identify the products that will best integrate with your existing tools and IT system infrastructure. 
We hope that you will seek products that are congruent with applicable standards and best practices. 
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315 Section 4.5, Technologies, lists the products that we used and maps them to the cybersecurity functions 

316 called out in the Cybersecurity Framework. 

317 A NIST Cybersecurity Practice Guide does not describe "the" solution, but a possible solution. This is a 

318 draft guide. We seek feedback on its contents and welcome your input. Comments, suggestions, and 

319 success stories will improve subsequent versions of this guide. Please contribute your thoughts to sidr- 

320 nccoe(g)nist.gov . 

321 2.1 Typographic Conventions 

322 The following table presents typographic conventions used in this volume. 


Typeface/Symbol 

Meaning 

Example 

Italics 

file names and path names; 
references to documents that 
are not hyperlinks; new 
terms; and placeholders 

For detailed definitions of terms, see 
the CSRC Glossary. 

Bold 

names of menus, options, 
command buttons, and fields 

Choose File > Edit. 

Monospace 

command-line input, 
on-screen computer output, 
sample code examples, and 
status codes 

Mkdir 

Monospace Bold 

command-line user input 
contrasted with computer 
output 

service sshd start 

blue text 

link to other parts of the 
document, a web URL, or an 

email address 

All publications from NIST's NCCoE 
are available at 

https://www.nccoe.nist.gov. 


323 3 Background 

324 Most of the routing infrastructure underpinning the internet currently lacks basic security services. In 

325 most cases, internet traffic must transit multiple ISPs before reaching its destination. Each network 

326 operator implicitly trusts other ISPs to provide (via BGP) the accurate information necessary for network 

327 traffic to be routed correctly. When that information is inaccurate, traffic will take inefficient paths 

328 through the internet, arrive at malicious sites that masquerade as legitimate destinations, or never 
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arrive at its intended destination. The consequences of these attacks can (1) deny access to internet 
services; (2) detour internet traffic to permit eavesdropping and to facilitate on-path attacks on 
endpoints (sites); (3) misdeliver internet network traffic to malicious endpoints, thereby providing the 
technical underpinning for other forms of cyberattack; (4) undermine IP address-based reputation and 
filtering systems; and (5) cause routing instability in the internet. These impacts can be mitigated 
through the widespread adoption of current and emerging internet routing security protocols. 

On April 8, 2010, nearly 15 percent of the world's internet traffic—including data from the United States 
(U.S.) Department of Defense and other U.S. government internet services—was redirected through 
computer networks in China [ N Anderson] . Between February and May 2014, network traffic from 51 
networks from 19 different ISPs was repeatedly hijacked in carefully crafted attacks aimed at stealing 
cryptocurrency [ A Greenberg] . In June 2015, a third-party ISP in Asia asserted that it was the most 
efficient route to the entire internet, disrupting traffic worldwide and resulting in customers 
experiencing severe network problems [ Saarinen] . In February 2008, YouTube became unreachable 
from most, if not all, of the internet. In an attempt to block access to a video that the Pakistani 
government considered blasphemous, Pakistan Telecom inadvertently redirected YouTube's traffic 
worldwide to an alternative site [ Singel] . While, to date, the impacts of these events range from a loss of 
access to social media to potential issues of national and economic security, they share a root 
cause: the internet's routing infrastructure currently relies on protocols that lack basic security services. 

This lack of security in the internet's routing infrastructure could be mitigated through the widespread 
adoption of current and emerging internet security protocols. The IETF, with significant contributions 
from the Department of Fiomeland Security and NIST, has developed standards and protocols to secure 
global internet routing. For example, the IETF has defined the RPKI, which is designed to secure the 
internet's routing infrastructure. The RPKI enables an enterprise to prove that it holds a range of 
internet addresses and to identify the ASes that the holder authorizes to originate routes to its 
addresses by using cryptographically verifiable ROAs. RPKI services are available today from the RIRs, 
which manage the allocation and registration of internet resources. Commercial routers are available 
today that are capable of using RPKI data to identify accidental errors in routing announcements by 
determining that the origin AS in the route contradicts an existing ROA in the RPKI. 

ROV provides good protection against accidental mis-origination of routes, but not necessarily against 
intentional (e.g., malicious) mis-origination of routes. If an attacker adds the AS number (of the AS that 
is authorized to originate a route) to the beginning of the AS path in a bogus BGP route update, in order 
to forge the origin AS in that update, then the bogus route update will pass ROV and will not be 
detected as bogus, even though it is, because ROV assumes that the AS path is correct, rather than 
providing any sort of integrity checking on the AS path. 

A separate protocol, BGPsec, augments RPKI-based ROV to detect these types of malicious route 
announcements by enabling network operators to verify the validity of the entire routing path across 
the internet (referred to as path validation), as opposed to just validating the authority of the originating 
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AS. If widely implemented together, ROV and BGPsec would significantly improve the security and 
stability of global internet routing. 

Unfortunately, the adoption of ROV and BGPsec security protocols has been slow due to impediments, 
such as usability, performance, and cost: 

■ Usability - Internet routing security mechanisms are to be implemented primarily by ISPs 
and ASes. As such, the usability impacts are felt mostly by systems administrators for those 
services. ISP and AS administrators are faced with relatively few application choices, immature 
documentation, relatively immature products, and relatively complex installation and 
configuration processes. Furthermore, adding more data, data sources, and maintainers to the 
BGP decision and policy frameworks imparts several new failure modes. Thus, an already 
complex troubleshooting landscape can get significantly more complex. 

■ Performance - Some increase in processing latency may occur due to processing associated with 
routing security protocols. With the use of RPKI to address ROV and the addition of an RPKI 
cache(s), new router operating systems (OSes) may have performance implications. A more 
significant performance issue is connection latency due to fewer routing path choices from 
improper configuration. BGPsec path validation introduces a different set of performance 
issues. The reduction in available paths would be due to ISP/AS interdependencies that 
exacerbate the effects of connection refusals due to path validation failures in a path when an 
ISP/AS has not implemented the required integrity verification functionality. As in the case of 
Domain Name System Security, many of the connection refusals may be due to certificate 
management difficulties. The BPGsec protocol to be used for path validation is expected to be 
resource intensive. Each BGP update will have one or more digital signatures in it, thereby 
increasing the size of the message. Every one of the AS hops in the AS path will have an 
associated digital signature that must be verified. Also, each update will be able to carry only a 
single prefix, so updates will be more numerous. 

■ Cost - Much of the cost associated with the implementation of ROV using RPKI involves an 
integration of the few, and still relatively immature, products into existing systems that have an 
installed applications base, complete with restrictive support agreements. For example, some 
vendors prohibit the installation of software other than that distributed by themselves. 
Immature documentation and relatively complex installation and configuration processes add to 
this labor cost impact. Support contract impacts also represent a very significant cost-based 
impediment to ROV implementation at this time. The cost of implementing BGPsec in the future 
may be significantly larger than RPKI-based ROV. Since ISPs and ASes will need to support an 
additional type of certificate that binds their AS number to a public key, additional provisions for 
RPKI and router processing resources (upgraded hardware and router memory) will be needed 
to support path validation. 

Other impediments to adoption include needed security features not being available from a vendor with 
which significant user sets have restrictive support contracts; incompatibility with potential users' 
installed bases; uncertainties associated with installation, integration, and activation processes; support 
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concerns on the part of potential users that rely on software subject to frequent updates; resistance to 
making changes that might change the user experience (regardless of user-experience improvements 
that may accrue); and simply not being on the potential user's already-approved long-term system 
development, upgrade, and support plans (road maps). 

The relative immaturity of available components and lack of ubiquitous support for those components 
are also impediments to the implementation of route origin and path validation protocols. 

Additional labor and support contract costs can result in competitive disadvantages. At least at first, 
mandating ROV can result in reduced routing path options (especially in the face of ISP/AS 
interdependencies), fewer partner relationship options, and fewer service delivery options. 

Although the adoption of both ROV and BGPsec may have been hindered for the reasons mentioned 
above, the adoption and deployment of BGPsec is expected to be even slower relative to that of ROV. 
Commercial BGPsec implementations are not currently available. Also, the use of digital signatures 
in BGPsec adds a level of complexity with respect to the acquisition and management of router public 
keys, as well as the X.509 certificates used in sharing those keys. The relative scarcity of key 
management tools means that implementing organizations spend significant expert labor resources on 
complex cryptographic key-related acquisition, installation, configuration, and management. 

ROV, on the other hand, has already been incorporated into the equipment of major vendors (i.e., it 
ships with Cisco, Juniper, and Alcatel/Lucent/Nokia routers), and all RIRs are in production mode with 
RPKI services. Furthermore, in some regions of the world, RIRs provide tools and support that facilitate 
the efficient implementation of these protocols. ROV adoption is sluggish in North America; there 
remains insufficient demand to motivate the adoption of RPKI on a large scale in this region. Customers 
do not demand ROV from their own network providers because the primary benefit would be to 
customers of other networks. Network providers are hesitant to invest in routing security since their 
customers do not demand it. Numerous governmental and industry road maps (e.g.. Federal 
Communications Commission Communications Security, Reliability and Interoperability Council III 
Working Groups 4 and 6 reports) do call for the incremental deployment of new BGP security 
technologies. Flowever, market pressure has been insufficient to overcome implementation constraints, 
and commercial adoption to date has been slow. 

This situation is beginning to change in other regions of the world. Europe, in particular, is approaching 
an ROA coverage of approximately 33 percent of its announced IPv4 address space, due in part to 
forward-looking adoption policies and favorable and flexible usage polices for RPKI services. North 
America trails Europe, Latin and South America, and Africa in its rate of adoption, with only 
approximately three percent of its announced IPv4 address space covered by ROA. 

Given the lack of commercial vendor implementation support for BGPsec, and other obstacles currently 
hindering its adoption, and given the more favorable position of ROV with respect to being standardized 
and incorporated into vendor equipment, this effort is initially focusing only on BGP ROV. 
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The proof-of-concept implementation described in this Practice Guide demonstrates the use of available 
hardware and software to mitigate impediments to the adoption of ROV protocols. It takes advantage of 
available tools to facilitate implementation, operation, and maintenance; to improve the performance 
of administration functions; and to reduce the labor requirements that are major contributors to 
implementation costs. It is anticipated that a successful demonstration of currently available products 
and tools that mitigate the impediments preventing individual institutions from implementing ROV will 
foster the increased implementation of routing security protocols to the point that interoperability 
considerations will favor global implementation. 

For hosted RPKI, an RIR provides the infrastructure to host the certificate authorities and private keys 
used to sign the ROAs for address blocks registered in the RIR's region. An ROA authorizes one or more 
route prefixes to be originated from an AS and is signed with the private key associated with the 
prefix holder's digital end-entity (EE) certificate. The ROA also specifies a maximum prefix length 
(maxLength) [RFC 6482] so that an announcement of prefixes longer than maxLength would be 
invalid. Address holders who are registered with the RIR and have received address allocations from 
it can access tools provided by the RIR to create and publish ROAs for those addresses. Those ROAs are 
stored in the RIR's RPKI repositories. Network operators around the world can retrieve the ROAs from 
the RIR RPKI repositories, validate their integrity and authenticity, and use the information in the ROAs 
to detect the validity of the origin AS in the received BGP updates. Depending on the ISP's or AS's policy, 
routes (i.e., updates) that fail^ ROV may be assigned a lower priority in route selection or may be 
discarded. For delegated RPKI, address holders (e.g., ISPs, large enterprises) operate a delegated RPKI 
certificate authority (CA) and their own publication point to store associated certificates, keys, and 
ROAs. This implementation model allows an ISP or other entity to offer hosted or delegated RPKI 
resources to its customers. This project focused on both the hosted RPKI model and the delegated RPKI 
model. 

4 Approach 

4.1 Audience 

This guide is intended for individuals responsible for implementing security solutions in organizations' IT 
support activities. The information provided in this Practice Guide permits the integration of ROV with 
minimum changes to existing infrastructure and with minimum impact to service operations. The 
technical components will appeal to system administrators, IT managers, IT security managers, and 
others directly involved in the secure and safe operation of the business IT networks. 
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4.2 Scope 

The scope of this project covers the roles of both address holders and network operators. Address 
holders (i.e., enterprises and providers of internet services) are responsible for creating RPKI content, 
such as ROAs, that can be used to validate that specific ASes are authorized to originate routes to the 
addresses that they hold. Network operators are responsible for providing BGP-based routing services to 
clients and their peer networks in other autonomous systems, and use the ROAs and other RPKI content 
to perform ROV. Note that the same entity may be both an address holder and a network operator. 

For address holders, the scope of this project includes demonstration of two implementation models of 
RPKI: hosted RPKI and delegated RPKI. 

A determination of the vulnerability of the RPKI repository to intrusion and malicious alterations of data 
was outside the scope of the project. The project included partners and Community of Interest (COI) 
collaborators from various classes of enterprises, and service providers that contributed to the design 
and conduct of tests in these areas. 

For network operators, the scope of the project focused on the deployment of, and scenarios for the use 
of, RPKI-ROA information in support of BGP ROV [RFC 6811] . The project tested the functionality of 
RPKI/ROV components and documented issues and best practices for the operation and use of RPKI 
validating caches (VCs) and ROV-capable BGP routers. It addressed issues of robustness and 
responsiveness of these components as well as routing policies that can be configured for them. The 
project included COI and National Cybersecurity Excellence Partnership (NCEP) partners to provide 
commercial off-the-shelf (COTS) and open-source products that implement the components necessary 
for BGP network operators to acquire, validate, and use RPKI information to implement BGP ROV. The 
project also included COI collaborators from various classes of network operators (e.g., enterprise, stub 
ISPs, regional networks, transit ISPs, internet exchange point operators) that contributed to the design 
and conduct of tests in realistic scenarios (e.g., BGP routing architectures, exterior border gateway 
protocol [eBGP] and interior border gateway protocol [iBGP], ISP architectures). 

For each deployment scenario, RPKI-based ROV functionality was validated, including various scenarios 
for BGP ROV results {valid, invalid, and not found [RFC 6811] ) and vendor implementation-specific 
options for RPKI-ROV-based filtering mechanisms. This project has resulted in this freely available NIST 
Cybersecurity Practice Guide describing steps to demonstrate, deploy, and manage RPKI-based ROV for 
both enterprises and network operators; identify implementation and interoperability issues; provide 
sample deployment architectures; and provide lessons learned from employing controls identified in 
NIST SP 800-53 . 

The IETF has also developed a new protocol called BGPsec, which provides cryptographic protection for 
the entire AS path in a BGP update. This security extension to BGP would help prevent AS path 
modification attacks (e.g., maliciously shortening the AS path to redirect traffic). Flowever, commercial 
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router implementations of BGPsec are not currently available. Hence, this effort initially focuses on BGP 
ROV, and consideration of the BGPsec protocol is currently outside the scope of this project. 

4.3 Assumptions 

This project assumes that most potential adopters of the demonstrated build or any build components 
do not already have RPKI-based ROV tools or mechanisms in place, but that they do already have routing 
systems. This document is intended to provide installation, configuration, and integration guidance and 
assumes that an organization has the technical resources to implement all or parts of the build or has 
access to companies that can perform the implementation on its behalf. The guidance provided in this 
document may be used to provide a complete top-to-bottom solution or may be applied in modular 
fashion to provide selected options based on need. It is intended that the benefits of adopting RPKI- 
based ROV outweigh any additional performance, reliability, or security risks that may be introduced by 
instantiating the protocols. 

RIRs play vital roles in RPKI, both in terms of assisting with the creation of RPKI content by address 
holders and in terms of making that content available to relying parties (RPs) via repositories that are 
hosted online. It is assumed that address holders understand the usage of RPKI resources. When using 
the hosted model, address holders must have agreements in place with an RIR or other hosting 
authority that enables the address holder to request that the host create, sign, and store ROAs for the 
address holders' addresses. When using the delegated model, the address holder must provide and 
manage its own RPKI infrastructure and CAto create, sign, store, and manage its own ROAs, rather than 
rely on a host to provide this infrastructure and services. For organizations that choose to use the 
delegated model and run their own CA, there is open-source software available to create the RPKI 
infrastructure and securely communicate with the RIR parent system. Network operators who provide 
BGP-based routing services are responsible for operating RPKI VCs and ROV-capable routers so that they 
can retrieve ROA information from RPKI repositories and use it to perform ROV on BGP updates that 
they receive. 

When a router applies ROV to a received BGP update, the router determines whether the update is 
valid, invalid, or not found. Valid routes should typically be installed into the routing table, but what a 
router does with invalid and not found routes is the prerogative of the organization that operates the 
router and will depend on local policy. Service provider policies may take into account whether there 
are requirements to forward routes to customers as well as local considerations. Enterprise policies will 
depend on enterprise-specific considerations. This project does not attempt to dictate the policies that 
any organization should implement. As a first step toward adoption, enterprises could simply perform 
ROV, and mark all routes as valid, invalid, or not found, but perform no further policy beyond simply 
observing the number of routes that are invalid and not found. 
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4.4 Risk Assessment 

While this guide does not present a full risk assessment as discussed in NIST SP 800-30 or NIST SP 800- 
37, it does describe the risks associated with unauthorized updates to routing information and identifies 
some route hijacking risks that may be addressed in follow-on project activities. 

NIST SP 800-30, Guide for Conducting Risk Assessments, states that risk is "a measure of the extent to 
which an entity is threatened by a potential circumstance or event, and typically a function of (i) the 
adverse impacts that would arise if the circumstance or event occurs and (ii) the likelihood of 
occurrence." The guide further defines risk assessment as "the process of identifying, estimating, and 
prioritizing risks to organizational operations (including mission, functions, image, reputation), 
organizational assets, individuals, other organizations, and the Nation, resulting from the operation of 
an information system. Part of risk management incorporates threat and vulnerability analyses, and 
considers mitigations provided by security controls planned or in place." 

The NCCoE recommends that any discussion of risk management, particularly at the enterprise level, 
begins with a comprehensive review of NIST SP 800-37, Guide for Applying the Risk Management 
Framework to Federal Information Systems — material that is available to the public. The risk 
management framework (RMF) guidance, as a whole, proved to be invaluable in giving us a baseline to 
assess risks, from which we developed the project, the security characteristics of the build, and this 
guide. 

4.4.1 Threats 

The lETF's Threat Model for BGP Path Security, RFC 7132, points out that BGP routers themselves can 
inject bogus routing information, either by masquerading as any other legitimate BGP router or by 
distributing unauthorized routing information as themselves. Flistorically, misconfigured and faulty 
routers have been responsible for widespread disruptions in the internet. As stated in RFC 4593, 
legitimate BGP peers have the context and information to produce believable, yet bogus, routing 
information, and therefore have the opportunity to cause great damage. Cryptographic protections and 
operational protections cannot necessarily exclude the bogus information arising from a legitimate peer. 

Threats to routing include deliberate exposure, sniffing, traffic analysis, spoofing, false route origination, 
interference, secure path downgrade, and overload. Of these, spoofing and false origination are most 
relevant to this project. 

■ Spoofing - Occurs when an illegitimate device assumes the identity of a legitimate one. 

Spoofing, in and of itself, is often not the true attack. Spoofing is special in that an attacker can 
use it as a means for launching other types of attacks. For example, if an attacker succeeds in 
spoofing the identity of a router, the attacker can send out unrealistic routing information that 
might cause the disruption of network services. There are a few cases where spoofing can be an 
attack in and of itself. For example, messages from an attacker that spoof the identity of a 
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legitimate router may cause a neighbor relationship to form and deny the formation of the 
relationship with the legitimate router. The primary consequence is that the authorized routers, 
which exchange routing messages with the spoofing router, do not realize that they are 
neighboring with a router that is faking another router's identity. Another consequence includes 
the spoofing router gaining access to the routing information. 

■ False route origination - An attacker sends false routing information. To falsify the routing 
information, an attacker has to be either the originator or a forwarder of the routing 
information. The attacker cannot be only a receiver. This project primarily addresses the 
falsification of route updates. Routers that legitimately forward routing protocol messages are 
expected to leave some fields unmodified and to modify other fields in certain circumscribed 
ways. The fields to be modified, the possible new contents of those fields, and their 
computation from the original fields—the fields that must remain unmodified, etc.—are all 
detailed in the protocol specification [RFC 4271] . These details may vary depending on the 
function of the router or its network environment. The primary threat here is misstatement, an 
action whereby the attacker modifies route attributes in an incorrect manner. In BGP, the 
attacker might delete some AS numbers from the AS path. When forwarding routing 
information that should not be modified, an attacker can launch the following falsifications: 

• Deletion - The attacker deletes valid data in the routing message. 

• Insertion - The attacker inserts false information in the routing message. 

• Substitution - The attacker replaces valid data in the routing message with false data. 

The threat consequences of these falsifications by forwarders include the usurpation of some 
network resources and related routers, deception of routers using false paths, and the 
disruption of data planes of routers on the false paths. RPKI-based ROV provides protection 
against deletions, insertions, and substitutions that result in an AS that is not authorized to 
originate a BGP update being listed as the origin of that update. To protect against attacks on 
other parts of the AS path, however, BGPsec is needed. 

A comprehensive treatment of threats to BGP path security (i.e., threats to other parts of the AS path 
besides the origin) can be found in IETF RFC 7132 . Of particular interest to this project are attacks on an 
RPKI—CA (Section 4.5 of the RFC) because not only path security, but also BGP ROV, relies on the RPKI. 
Every entity to which Internet Number Resources (INRs)^ have been allocated/assigned is a CA in the 
RPKI. Each CA is nominally responsible for managing the repository publication point for the set of 
signed products that it generates. An INR holder may choose to outsource the operation of the RPKI CA 
function and the associated publication point. In such cases, the organization operating on behalf of the 
INR holder becomes the CA from an operational and security perspective. Note that attacks attributable 
to a CA may be the result of malice by the CA (i.e., the CA is the adversary), or they may result from a 
compromise of the CA. 
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The RPKI, upon which BGP ROV and path security relies, has several residual vulnerabilities that are 
discussed in Sections 4.4 and 4.5 of RFC 7132 . These vulnerabilities are of two principal forms: 

■ The RPKI repository system may be attacked in ways that make its contents unavailable, not 
current, or inconsistent.^ The principal defense against most forms of such DoS attacks is the use 
of a validating cache by each RP. The validating cache ensures the availability of previously 
acquired RPKI data in the event that a repository is inaccessible or the repository contents are 
deleted (maliciously). Nonetheless, the use of a validating cache cannot ensure that every RP 
will always have access to up-to-date RPKI data. An RP, when it detects a problem with 
acquired repository data, has two options: 

• The RP may choose to make use of its validating cache, employing configuration settings 
that tolerate expired or stale objects. (Such behavior is, nominally, always within the 
purview of an RP.) Using cached, expired, or stale data subjects the RP to attacks that take 
advantage of the RP's ignorance of changes to this data. 

• The RP may choose to purge expired objects. Purging expired objects removes the security 
information associated with the real-world INRs to which the objects refer. This is 
equivalent to the affected INRs not having been afforded protection via the RPKI. Since use 
of the RPKI is voluntary, there may always be a set of INRs that are not protected by these 
mechanisms. Thus, purging moves the affected INRs to the set of non-participating INR 
holders. This more conservative response enables an attacker to move INRs from the 
protected set to the unprotected set. 

Any CA in the RPKI may misbehave within the bounds of the INRs allocated to it (e.g., it may 
issue certificates with duplicate resource allocations or revoke certificates inappropriately). This 
vulnerability is intrinsic in any Public Key Infrastructure (PKI), but its impact is limited in the RPKI 
because of the use of the X.509 certificate extensions defined in RFC 3779 to bind lists of 
prefixes or AS identifiers to the subject of a certificate. It is anticipated that RPs will deal with 
such misbehavior through administrative means once it is detected. 

4.4.2 Vulnerabilities 

Border Gateway Protocol 4 ( BGP-4 ) was designed before the internet environment became perilous, and 
it was originally designed with little consideration for the protection of the information it carries. There 
were originally no mechanisms internal to BGP that protect against attacks that modify, delete, forge, or 
replay data, any of which has the potential to disrupt overall network routing behavior. (See IETF RFC 
4272 for a BGP security vulnerabilities analysis.) Except for RPKI-based ROV and mechanisms described 
in BGPsec [RFC 8205], BGP still does not include mechanisms that allow an AS to verify the legitimacy 
and authenticity of BGP route advertisements. BGP does, however, mandate support for mechanisms to 
secure peer-to-peer communication (i.e., the links that connect BGP routers). 
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The MITRE Corporation's Common Vulnerability and Exposures (CVE) lists more than 85,000 
vulnerabilities that can affect the security of information carried over internet services. The full set of 
vulnerabilities includes elements beyond the scope of this project (e.g., Structured Query Language 
[SQL]'^ servers, Domain Name System servers, firewalls, routers, other network components 
[ https://cve.mitre.org] ). The CVE includes specific vulnerabilities inherent in BGP protocols [ RFC 4271] . 
As in the case of client systems vulnerabilities, NIST's National Vulnerability Database 
( https://nvd.nist.gov) is a frequently updated source of vulnerabilities that affect network servers. 

4.4.3 Risks 

There is a variety of risks resulting from the possibility that vulnerabilities to BGP routing may be 
exploited. Some examples include the unavailability of services on which revenue depends, legal 
liability, stimulation of regulatory initiatives, loss of productivity, and damage to organizational 
reputation. These breaches can be accidental, but they can also be intentional. 

■ With respect to both service availability and legal liability, failure to deliver services on which 
customers are dependent can result in multimillion-dollar torts or contract penalties. 

■ Flarm to, or denial of access to, the critical infrastructure and its services have occurred and, if 
egregious or excessively frequent, may stimulate executive or legislative initiatives imposing 
security regulations on currently unregulated industries. 

■ The time and labor expended in recovering from routing-based attacks can result in the loss of 
operational and maintenance productivity. 

■ The loss of services on which customers depend can result in a loss of confidence in the 
reliability of the organization and can do long-term damage to the organization's reputation. 

The use of the Framework Core is recommended to reduce these risks. The Framework Core, identified 
in NIST's Framework for Improving Critical Infrastructure Cybersecurity , is a set of cybersecurity 
activities, desired outcomes, and applicable references that are common across critical infrastructure 
sectors. The Core presents industry standards, guidelines, and practices in a manner that allows for the 
communication of cybersecurity activities and outcomes across the organization from the executive 
level to the implementation/operations level. The Framework Core consists of five concurrent and 
continuous/uncf/ons—Identify, Protect, Detect, Respond, and Recover. When considered together, 
these functions provide a high-level, strategic view of the life cycle of an organization's management of 
cybersecurity risk. 

4.4.4 Cybersecurity Framework Functions, Categories, and Subcategories Addressed 
by the Secure Inter-Domain Routing Project 

Implementation of the security platform described in this publication addresses aspects of the Protect 
(PR), Detect (DE), Respond (RS), and Identify (ID) functions of the Cybersecurity Framework, as shown in 
Table 4-1 . For a more detailed discussion of how the various components of the SIDR reference 
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682 architecture solution support specific subcategories of the Cybersecurity Framework, as well as a 

683 discussion of additional references, standards, and guidelines that informed the SIDR Project, refer to 

684 Appendix D . 

685 Table 4-1 Security Control Mapping of Cybersecurity Framework Subcategories to Capabilities of the 

686 SIDR Reference Architecture Solution 


Example Characteristic 

Cybersecurity Standards and Best Practices 

Security Example 

Characteristics Capability 

Function Category 

^ , Informative 

Subcategory „ , 

References 


Integrity and 
Authenticity 

Ensure that BGP 

routes are 
originated by 
authorized ASes 

PROTECT 

(PR) 

Data Security 
(PR.DS) 

PR.DS-1, 

PR.DS2, 

PR.DS-6 

ISO/IEC 

27001:2013 

A.8.2.3, 

A. 13.1.1, 

A. 13.2.1, 

A. 13.2.3, 

A. 14.1.2, 
A.14.1.3 






NIST SP 800- 

53 Rev. 4 

SC-8, SC-28 



DETECT 

(DE) 

Security 

Continuous 

Monitoring 

(DE.CM) 

DE.CM-4, 

DE.CM-7 

ISO/IEC 

27001:2013 

A.12.2.1 

NIST SP 800- 

53 Rev. 4 

AU-12, CA-7, 
CM-3, CM-8, 
PE-3, PE-6, 
PE-20, SI-3, 

SI-4 




Detection 

Processes 

(DE.DP) 

DE.DP-3 

ISO/IEC 

27001:2013 

A.14.2.8 






NIST SP 800- 

53 Rev. 4 
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Example Characteristic 

Cybersecurity Standards and Best Practices 


Security 

Characteristics 

Example 

Capability 

Function 

Category 

Subcategory 

Informative 

References 






CA-2, CA-7, 
PE-3, PM-14, 
SI-3, SI-4 

Anomalous 

Route 

Detection 

Ensure the 

detection of 

unauthorized 

routes to block 
misrouting or to 
report the 
anomalous 

events 

DETECT 

(DE) 

Detection 

Processes 

(DE.DP) 

DE.DP-4 

ISO/IEC 

27001:2013 

A.16.1.2 

NIST SP 800- 

53 Rev. 4 

AU-6, CA-2, 
CA-7, RA-5, 

SI-4 

System and 
Application 
Hardening 

Adjust security 
controls on the 
server and/or 
software 
applications such 
that security is 
maximized 
("hardened") 
while maintaining 
intended use 

PROTECT 

(PR) 

Information 

Protection 

Processes and 

Procedures 

(PR.IP) 

PR.IP-1, 

PR.IP-2 

ISO/IEC 

27001:2013 

A.6.1.5, 

A.12.1.2, 

A.12.5.1, 

A.12.6.2, 

A. 14.1.1, 

A. 14.2.1, 

A. 14.2.2, 
A.14.2.3, 

A. 14.2.4, 
A.14.2.5 






NIST SP 800- 

53 Rev. 4 
CM-2, CM-3, 
CM-4, CM-5, 
CM-6, CM-7, 
CM-9, PL-8, 
SA-3, SA-4, 
SA-8, SA-10, 
SA-11, 

SA-12, 
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Example Characteristic 

Cybersecurity Standards and Best Practices 


Security 

Characteristics 

Example 

Capability 

Function 

Category 

Subcategory 

Informative 

References 






SA-15, 

SA-17 

Device 

Protection 

Ensure the 
protection of 
devices, 

communications, 
and control 

networks 

PROTECT 

(PR) 

Access Control 
(PR.AC) 

PR.AC-3, 

PR.AC-5 

ISO/IEC 

27001:2013 

A.6.2.2, 

A. 13.1.1, 

A. 13.1.3, 

A. 13.2.1 






NIST SP 800- 

53 Rev. 4 

AC-4, AC-17, 
AC-19, 

AC-20, SC-7 



PROTECT 

(PR) 

Protective 

Technology 

(PR.PT) 

PR.PT-4 

ISO/IEC 

27001:2013 

A. 13.1.1, 

A. 13.2.1 






NIST SP 800- 

53 Rev. 4 

AC-4, AC-17, 
AC-18, CP-8, 

SC-7 

Incident 

Response 

Ensure the 
integrity of 
network 

connections in 

the case of 

incidents that 

result in a 
compromise; the 
effects of 
the compromise 
can be limited by 
exclusion of 

RESPOND 

(RS) 

Communications 

(RS.CO) 

RS.CO-2, 

RS.CO-3 

ISO/IEC 

27001:2013 

A.6.1.3, 
A.16.1.2, 
Clause 7.4, 
Clause 

16.1.2 

NIST SP 800- 

53 Rev. 4 

AU-6, CA-2, 
CA-7, CP-2, 
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Example Characteristic 

Cybersecurity Standards and Best Practices 

Security 

Characteristics 

Example 

Capability 

Function 

Category 

Subcategory 

Informative 

References 


systems and 
devices that have 
not implemented 
the integrity 
mechanisms; 
when routes that 




IR-4, IR-6, 

IR-8, PE-6, 
RA-5, SI-4 


originated from 
unauthorized 

ASes are 
received, these 
can be logged 
and reported 

RESPOND 

(RS) 

Mitigation 

(RS.MI) 

RS.MI-1 

ISO/IEC 

27001:2013 

A.16.1.5 

NIST SP 800- 

53 Rev. 4 

IR-4 
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687 4.5 Technologies 

688 Table 4-2 lists all of the technologies used in this project and provides a mapping among the generic 

689 application term, the specific product used, and the security control(s) that the product provides. 

690 Table 4-2 Products and Technologies 


Component 

Product 

ROV- 

Cisco 

enabled 

7206VXR 

Router 

Cisco 4331 


Cisco 2921 


Cisco lOS 


XRv 9000 


Juniper 
MX80 3D 
Universal 
Edge 


How Component Functions 


Receives BGP updates; evaluates 
routes; and installs routes 
according to policy, thereby 
protecting network routing 
integrity and, by extension, data- 
in-transit and the communication 
network as a whole. Application 
of ROV monitors the network for 
routes that have been originated 
without authorization. Invalid 
and not found routes can be 
tagged and reported; rejection of 
invalid routes may help contain 
or mitigate incidents. 


Cybersecurity Framework 
Subcategories 


ID.AM-3: Organizational 
communication and data 
flows are mapped. 

ID.AM-4: External information 
systems are catalogued. 

PR.AC-5: Network integrity is 
protected, incorporating 
network segregation where 
appropriate. 

PR.DS-2: Data-in-transit is 
protected. 

PR.DS-6: Integrity-checking 
mechanisms are used to verify 
software, firmware, 
and information integrity. 
PR.PT-4: Communications and 
control networks are 
protected. 

DE.CM-1: The network is 
monitored to detect potential 
cybersecurity events. 

DE.CM-6: External service 
provider activity is monitored 
to detect potential 
cybersecurity events. 

DE.CM-7: Monitoring for 
unauthorized personnel, 
connections, devices, and 
software is performed. 
RS.CO-2: Events are reported 
consistent with established 
criteria. 
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Component 

Product 

How Component Functions 

Cybersecurity Framework 
Subcategories 




RS.MI-l: Incidents are 

contained. 

RS.MI-2: Incidents are 
mitigated. 

RPKI CA 

Dragon 
Research 
rpki.net RPKI 
toolkit 

Functions as a certificate 
authority that contains resource 
certificates attesting to holdings 
of IP address space and AS 
numbers, and that can issue EE 
certificates and ROAs for 
addresses within this space. 

PR.AC-1: Identities and 
credentials are managed for 
authorized devices and users. 

RPKI 

Repository 

Dragon 
Research 
rpki.net RPKI 
toolkit 

Functions as a trusted repository 
of RPKI information that makes 
signed RPKI information, such as 
ROAs, available to RPs. 

PR.AC-1: Identities and 
credentials are managed for 
authorized devices and users. 

VCs 

ReseauxIP 
Europeens 
Network 

Coordination 
Centre (RIPE 
NCC) 

Validator 

RP software; RPKI data from 
trusted repository is downloaded 
to this component and validated; 
functions as a validating cache 
with which the ROV-enabled 

router interacts. 

PR.AC-1: Identities and 
credentials are managed for 
authorized devices and users. 

PR.AC-3: Remote access is 
managed. 


Dragon 
Research 
rpki.net RPKI 
toolkit 



Circuit 

CenturyLink 

1 Gigabit per 
second 
(Gbps) 
Ethernet 

Link 

Connectivity to internet. 

PR.AC-3: Remote access is 
managed. 

Firewall 

Palo Alto 

Networks 

Next- 

generation 
Firewall PA- 

5060 

Firewall protecting lab network 
from internet. 

PR.AC-3: Remote access is 
managed. 
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691 4.5.1 ROV-Enabled Routers 

692 The participating router vendors are Cisco and Juniper. These routers contain OSes that can perform 

693 ROV. The protocol used by these routers to communicate to the VCs is the RPKI-Router protocol 

694 [RFC 6810], [RFC 8210] , The routers connect to a 1 Gbps Ethernet link provided by CenturyLink. Route 

695 advertisements and updates are provided through this link. The routers connect to the virtual 

696 environments that represent their AS infrastructure through 1 Gbps Ethernet links. 

697 4.5.1.1 Cisco Routers 

698 Cisco routers used in the lab are Cisco 7206VXR^ routers. These "wide area network edge" routers have 

699 the following features: support for BGP ROV [RFC 6810], [RFC 6811]; Quality of Service; Multiprotocol 

700 Label Switching; and Voice over IP. They support various interfaces, such as Gigabit Ethernet using 

701 copper or fiber, mixed-enabled Tl/El, and Packet over Synchronous Optical Network (SONET). 

702 4.5.1.2 Juniper Routers 

703 Juniper routers used in this lab build are MX80 3D Universal Edge.® These routers are described as best 

704 used for wide area network. Data Center Interconnect, branch aggregation, and campus applications. 

705 They have 10 Gigabits Ethernet (GbE) and modular interface capabilities for supporting a variety of 

706 interfaces, including RFCs 6810 and 6811 . 

707 4.5.2 RPKI Certificate Authority 

708 One of the components of the Dragon Research rpki.net RPKI toolkit is software that functions as a CA 

709 that enables resource certificates attesting to holdings of IP address space and AS numbers, EE 

710 certificates, and ROAs to be created and signed. The Dragon Research rpki.net software is open source 

711 and available via GitFlub at https://github.com/dragonresearch/rpki.net . 

712 Note: The above link provides the toolkit, which includes the RPKI CA, repository, and validating cache. 

713 4.5.3 RPKI Repository 

714 A second component of the Dragon Research rpki.net RPKI toolkit is software that functions as an RPKI 

715 repository that stores RPKI information and makes it available to RPs for use in ROV. 

716 4.5.4 Validating Caches 

717 Two different open-source software products were used in the build to serve as VCs: the RIPE NCC 

718 Validator, which is recommended for use by the American Registry for Internet Numbers (ARIN), and a 

719 third component of the Dragon Research RPKI toolkit, which ARIN also references. 
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4.5.5 Circuit 

CenturyLink provided a 1 Gbps circuit that provided connectivity from our laboratory architecture to the 
internet, through which the RPKI repository system could be accessed, and a full BGP route table was 
provided. 

4.5.6 Firewall 

Palo Alto provided a model PA-5060 firewall to protect the lab infrastructure from internet traffic. The 
firewall provides protection against known and unknown threats. In this deployment, only the ports and 
connections necessary for the build are configured. All other ports and connections are denied. 

5 Architecture 

5.1 Overall RPKI-Based ROV Reference Architecture 

ROV depends on two separate, complementary functions being performed: ROA creation and ROV. To 
build a robust RPKI infrastructure to support ROV, all address holders (i.e., all entities that have been 
allocated IP address space) should ensure that ROAs for their addresses are created, signed, and stored 
in an RPKI repository system. The RPKI repository system will then make these ROAs and other RPKI 
information available for use by network operators to perform ROV on the BGP route updates that they 
receive. Hence, conceptually, there are two reference architectures necessary for supporting RPKI-based 
ROV: the ROV reference architecture, which is implemented by network operators and is used to 
perform ROV ( Section 5.1.1, Figure 5-1 ), and the RPKI reference architecture, which is implemented by 
address holders and is used to create and store RPKI information (e.g., ROAs) ( Section 5.1.2, Figure 5-2 
and Figure 5-3) . 

Note that all network operators are also address holders, so network operators will typically implement 
both reference architectures. On the other hand, not all address holders are network operators, so 
some address holders (e.g., enterprises that rely on upstream ISPs to perform ROV on their behalf) may 
implement only the RPKI reference architecture; there is no reason for these address holders to 
implement the ROV reference architecture because they will not be performing ROV. 

5.1.1 ROV Reference Architecture 

Figure 5-1 depicts the reference architecture for ROV. As can be seen in Figure 5-1, only three 
components are needed to perform ROV: an ROV-capable router, a VC, and access to global RPKI 
repositories. Typically, but not necessarily, the trusted RPKI repositories will be repositories that are 
hosted by an RIR. This architecture is not intended to represent physical connectivity among the 
architecture components. Instead, it is meant to illustrate how they exchange information with each 
other. 
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Figure 5-1 The ROV Portion of the RPKI-Based ROV Reference Architecture 



The network operator must deploy two components to perform ROV: 

■ RPKI VC 

• The Remote Synchronization (rsync) protocol is required to support interoperability 
between the RPKI VC and the trusted RPKI repositories. RPKI Repository Delta Protocol 
(RRDP) [RFC 8182] is also supported by some RIRs for this same purpose. 

• The RPKI-to-router protocol [RFC 6810] is required to support interoperability between the 
RPKI VC and the local ROV-enabled routers, route reflectors, and route servers. 
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■ ROV-enabled BGP routers 

ROV policy options should be configured on these routers according to network operator policy 
and according to the network operator's status: 

• Stub AS (i.e., Enterprise) ROV policy configurations 

• Transit AS (i.e., ISP) ROV policy configurations 

• Intra-AS ROV policy configuration (iBGP ROV signaling [RFC 8097], monitoring, and 
management) 

It is a matter of local policy regarding what action should be taken when an incoming BGP route update 
is determined to be valid, invalid, or not found. Flowever, the particular actions that are configured to be 
performed will likely depend on the location of the BGP router that is validating the update 
(i.e., whether it is located within an ISP that the advertisement is transiting, whether it is located in a 
stub network, and whether it is an Internet Exchange Point router), as well as on the business model of 
the entity performing the ROV. More discussion of the considerations related to ROV policy are 
discussed in the Outcome section ( Section 6 ). 

5.1.2 RPKI Reference Architecture 

The RPKI reference architecture is used by address holders to create, sign, manage, and store ROAs. ROA 
information is the foundation on which routers and networks perform ROV. However, not all address 
holders share a single, uniform perspective of the RPKI reference architecture. Address holders may 
create ROAs by using either the hosted model or the delegated model, and the structure of the RPKI 
reference architecture differs according to which of these models is being used. Figure 5-2 
( Section 5.1.2.1) depicts the RPKI reference architecture as implemented by address holders using the 
hosted model, and Figure 5-3 ( Section 5.1.2. 2 ) depicts the RPKI reference architecture as implemented 
by address holders using the delegated model. 


NIST SP 1800-14B: Protecting the Integrity of Internet Routing 


26 









784 

785 

786 

787 

788 

789 

790 

791 

792 

793 

794 

795 

796 

797 

798 

799 

800 

801 

802 


DRAFT 


5.1.2.1 Hosted-Model RPKI Reference Architecture 

Figure 5-2 The Hosted-Model RPKI Reference Architecture 



Figure 5-2 depicts the reference architecture for hosted-model RPKI. As can be seen in the figure, an 
address holder wishing to use the hosted model of RPKI for ROA creation and storage needs to only have 
a web interface to the RIR or other authority from which it was allocated its addresses, and other 
resources. As with Figure 5-1, this architecture is not intended to represent physical connectivity among 
the architecture components. Instead, it is meant to illustrate how they exchange information with each 
other. 

In the hosted model, an RIR (or other authority) is responsible for operating an RPKI CA and repository. 
The RIR creates and signs ROAs for resources that are within the region that it oversees and that it has 
allocated. It also stores the ROAs in its repository. The address holder uses a tool (i.e., a web interface) 
to request that this RIR or other authority create, sign, manage, and store ROAs for its addresses on its 
behalf. In this model, the address holder does not have any responsibility to stand up or maintain a CA 
or repository or to directly create or maintain any of the RPKI information stored in it. All tools and 
applications for creating ROAs reside in the RIRs (or another organization that is hosting the RPKI 
service). RIRs provide the infrastructure and tools to create and store EE certificates, ROAs, and other 
RPKI information. Network operators are able to pull ROA information from the RIR (or other authority) 
repositories and use it to perform ROV. 
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5.1.2.2 Delegated-Model RPKI Reference Architecture 

Figure 5-3 The Delegated-Model RPKI Reference Architecture 

RIR RPKI 
Repositories 

The parent (RIR) 
repository points to 
the delegated 
repository 




CA and 
Repository 

The address holder 
populates the delegated 
repository with ROAs for its 
own addresses 


Address Holder's 
Autonomous System (AS) 


Figure 5-3 depicts the reference architecture for the delegated-model RPKI. As can be seen in the figure, 
the delegated model of RPKI for ROA creation and storage requires that two components be set up, 
operated, and maintained by the address holder: a CA and a repository. As with Figure 5-1 and 
Figure 5-2, this architecture is not intended to represent physical connectivity among the architecture 
components. Instead, it is meant to illustrate how they exchange information with each other. 

In addition to setting up these components, the address holder must obtain an authorization to sub¬ 
allocate these resources from the RIR or other authority from which it received its address and other 
resource allocations as well as a CA certificate for these resources. The address holder must store the 
private key of its delegated RPKI key pair, exchange the public keys of the key pairs that it creates with 
its RIR, and store the resource certificates and ROAs in its repository. The CA certificate that the address 
holder receives from its RIR attests to the fact that the resources have been allocated. When it sub¬ 
allocates resources, the address holder may use its CA certificate to issue resource certificates that 
attest to these sub-allocations. If the address holder has customers to which it sub-allocates addresses, 
it can offer a hosted model of RPKI to its customers by creating and storing ROAs on behalf of those 
customers. Alternatively, if the resource holder has customers who want to set up their own delegated 
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model of RPKI, it can authorize them to do so and can provide them with CA certificates attesting to 
their sub-allocations. 

The address holder uses its CA certificate to generate EE certificates and thereby create and sign ROAs 
for addresses in its allocation, rather than rely on the RIR (or another authority) to do so. Once it creates 
and signs ROAs, it stores them in its repository and makes them available to VCs via the rsync or RRDP 
protocol. Network operators performing ROV are able to locate the delegated repository because the 
repository of the RIR (or other authority) that allocated the resources to the address holder will point to 
the delegated repository. Hence, although the parent repository is not actually part of the delegated 
RPKI reference model, the fact that it points to the delegated RPKI repository is crucial. 

Because the applications and infrastructure for creating and storing ROAs reside in the address holder's 
network, the address holder itself, rather than an RIR or other outside entity, is responsible for the 
accessibility, robustness, and responsiveness of the delegated CA and repository. As the operator of the 
CA and repository, the address holder is also responsible for resource certification maintenance; ROA 
creation, maintenance, and revocation; as well as RPKI management, monitoring, and debugging, as 
needed. For many organizations, the responsibilities of running a delegated CA, such as the availability 
and complexity of setting up a CA in a secure fashion, the relative lack of availability of software 
products supporting the delegated model, developing a Certification Practice Statement, maintaining 
hardware security modules, and managing the delegated model repository, are found to be 
burdensome. In addition, there are many issues with running a CA in a delegated model [SP 800-57 Part 
^ [RFC 6484], [RFC 7382] . Available products for supporting the delegated model are limited and were 
not offered for this project. Consequently, the proof-of-concept demonstration focused mostly on the 
hosted model. 

5.2 Combined ROV and RPKI Reference Architecture Example 

Figure 5-4 depicts examples of all three reference architectures (ROV, hosted RPKI, and delegated RPKI) 
in one realistic network diagram. It shows three autonomous systems (AS A, AS B, and AS C), each of 
which is capable of participating in RPKI-based ROV, both as a network operator and as an address 
holder. Figure 5-4 also includes icons representing RIR RPKI CAs and repositories. 
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Figure 5-4 Example ROV and RPKI Reference Architectures 



Viewing the architecture in Figure 5-4 in terms of its depiction of address holders, AS A represents an 
address holder that is implementing the delegated model of RPKI. This AS has set up its own CA and 
repository and is responsible for creating, signing, and storing ROAs for the addresses that it holds and 
for any addresses that it may sub-allocate to its customers. ROAs for all addresses that have been 
allocated to AS A must be downloaded from the repository that is associated with AS A. Assuming that 
AS A received its address allocation from an RIR, that RIR's repository will point to AS A's repository. 

On the other hand, AS B and AS C represent address holders that are implementing the hosted model of 
RPKI. They have not set up their own CA or repositories. When they want to have ROAs created for the 
addresses that they hold, they must request that the entity that allocated the addresses to them 
creates, signs, and stores the ROAs on their behalf. AS B or AS C may have received its address allocation 
from its RIR, in which case it would use a tool (i.e., a web interface to an RIR tool) to request that the RIR 
creates, manages, and stores its ROAs. Alternatively, AS B or AS C may have received its 
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862 address allocation from its ISP (i.e., from AS A). In this case, it would rely on AS A to create, manage, and 

863 store its ROAs. 

864 Viewing the architecture in Figure 5-4 in terms of its depiction of network operators, all three ASes are 

865 network operators that are capable of performing ROV on all BGP updates that they receive. In order to 

866 perform ROV, a network operator must have an ROV-capable router, a VC (local or remote), and the 

867 ability for its VC to connect to its RPKI trust anchor (i.e., to the repository associated with AS A or to one 

868 of the RIR repositories). 

869 Usage scenarios for ROV and for the RPKI hosted and delegated models are discussed in the following 

870 section. 
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5.3 Usage Scenarios 

5.3.1 ROV Usage Scenario 

Figure 5-5 depicts the steps of an ROV usage scenario. 


Figure 5-5 Route Origin Validation Usage Scenario 



In this scenario, it is assumed that some address holders have created ROAs for the addresses that they 
hold. These ROAs are stored in the RPKI repository system, and network operators use these ROAs as 
the basis on which to perform the ROV. The steps of the ROV usage scenario, which are performed by AS 
64501 and AS 64502 in their role as network operators, are as follows: 

1. ROA information is pulled down to the RPKI VC (labelled "RPKI Cache") in AS 64501 and AS 
64502 by using the remote file synchronization protocol rsync or RRDP between the RIR 
repositories and the VC. 
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2. The RPKI VC receives all ROAs and certificates from the RIR repositories and validates this 
information. 

3. In AS 64501 and AS 64502, the RPKI VC communicates with the local eBGP router to send 
validated ROA payload (VRP) data to the router using the RPKI-router protocol. 

4. Each eBGP router receives BGP updates from its neighbors. 

5. Each eBGP router checks the BGP updates against the VRP information received from the RPKI 
VC and uses this information to evaluate each update as valid, invalid, or not found. 

6. Each eBGP router makes a routing decision, based on ROV policies, regarding what to do with 
the route. (Generally, if the route is found to be valid, it will be accepted. How invalid or not 
found routes are acted upon depends on local policy.) 

5.3.2 Hosted-Model Usage Scenario 

To understand the hosted model of RPKI in the context of Figure 5-2, assume that both AS 64501 and AS 
64502 (in their role as address holders) have received their IP address allocations from their RIRs. These 
ASes are responsible for ROA creation, maintenance, and revocation for the addresses that they hold. 
However, they do not have a locally deployed CA or repository. To create ROAs, these ASes would have 
to use the hosted model. They would register with their RIR and use its web interface to request that it 
create, sign, and store ROAs for the addresses that they were allocated by that RIR. 

5.3.3 Delegated-Model Usage Scenario 

In the context of Figure 5-6, the ISP in AS 64501 is hosting a delegated model of RPKI. It is authorized by 
the RIR from which it received its IP addresses to sub-allocate those addresses and issue CA certificates 
for those sub-allocations. It has set up its own certificate authority to create and sign ROAs for these 
addresses, as well as a repository to store these ROAs and other RPKI data and make them available to 
network operators that want to perform ROV. It has also ensured that its parent RIR repository points to 
the repository that is associated with its own AS. 
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Figure 5-6 Delegated-Model RPKI Usage Scenario 



5.4 SIDR Laboratory Architecture 

The SIDR laboratory's physical architecture is depicted in Figure 5-7 . It consists of virtual and physical 
hardware, and a physical circuit to CenturyLink, which provides connectivity to the internet where the 
RIRs reside. The architecture is organized into eight separate networks, each of which is designed to 
represent a different AS. For example, the network labelled 10.10.0.0/16 represents a transit ISP with AS 
65501, the network labelled 10.50.0.0/16 represents a stub enterprise network of an organization with 
AS 65505, etc. The physical hardware mainly consists of the routers performing ROV and the firewalls 
that protect the lab infrastructure. The virtual environment hosts the various software components 
needed to implement the ROV and RPKI reference architectures: a local RPKI repository in AS 65501 that 
is needed to implement the delegated model of RPKI, and various VCs in several ASes that are needed to 
perform ROV. Four network operators are capable of performing ROV, each of which is depicted as 
having a local VC: AS 65501, AS 65504, AS 65505, and AS 65507. AS 65500, AS 65502, AS 65503, and AS 
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921 65508 do not have validated caches and therefore lack the necessary infrastructure to perform ROV. In 

922 Figure 5-7, AS 65508 is colored red to represent a malicious attacker that may originate unauthorized 

923 BGP updates in an attempt to hijack routes. 
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924 Figure 5-7 SIDR Lab Physical Architecture 


925 
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The architecture is designed to support a demonstration of both the hosted model and the delegated 
model. 

Unfortunately, for the hosted model, we did not have address allocations from RIRs or agreements in 
place with RIRs that would give us access to the RIR to create and store ROAs at their repositories. To 
demonstrate the hosted model without access to RIR ROA creation tools, we set up a root CA and 
repository in AS 65501 (denoted by the Notional RIR CA/Repository icon in Figure 5-7) and used it to 
represent a notional RIR. ROAs for AS 65504 and AS 65507 could be stored in the Notional RIR repository 
just as they would typically be stored in an RIR repository if they had received their address allocations 
directly from an RIR rather than from our notional RIR. 

In Figure 5-7, the delegated model is represented by the icon labelled Delegated CA and Repository that 
is located within AS 65501 in the Service Providers Cloud. This delegated CA is set up as a child of 
the notional RIR CA, which, for purposes of simplifying the design, resides on the same subnet. The 
delegated CA represents a delegated model of RPKI infrastructure that AS 65501 has set up in its own AS 
to host its own repository and to create and store certificates and ROAs for the addresses that have 
been allocated to it by the notional RIR. It can store ROAs not only for AS 65501 in this repository, but 
also for AS 6550rs customer, AS 65505, to whom AS 65501 is assumed to have sub-allocated addresses. 
Flence, while the delegated CA and repository in AS 65501 represent a delegated RPKI model from the 
perspective of AS 65501, this model also offers a hosted RPKI service to AS 65505, which does not 
operate its own repository. As a customer of AS 65501, AS 65505 relies on AS 65501, rather than on the 
notional RIR, to create, sign, store, and maintain its ROAs. 

For purposes of ROV, network operators in all ROV-capable ASes were able to pull down ROAs and other 
RPKI information not only from the real RIRs, but also from the notional RIR repository and the 
delegated repository in AS 65501. 

6 Outcome 

This section discusses ROV-related issues, lessons learned, and best practices. 

6.1 ROV Policy Configuration Options 

The action to be taken when an incoming BGP route advertisement is determined to be valid, invalid, or 
not found is determined by local policy. Ultimately, when RPKI adoption has attained a high level of 
maturity, it is expected that the recommendation will be to drop invalid routes. Until then, invalid routes 
can be observed and noted, or perhaps assigned lower local preference (LP) values in order to de¬ 
preference them by using policies. 

Both Cisco and Juniper provided example policies for organizations to consider deploying with their 
ROV-capable routers. One candidate policy is to not drop invalid BGP updates. Another is to associate 
varying LP values with routes, depending on how the update that advertised the route is evaluated. For 
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example, routes received in valid updates may be given an LP value higher than the default, routes 
received in not found updates may be given the default LP value, and routes received in invalid updates 
may be given an LP value lower than the default. 

In addition, researchers affiliated with NIST and the IETF SIDR Working Group are also working to 
investigate and develop how the ROV-capable routers should best use the ROV state in route selection 
policy. 

6.2 Implementation Status of RPKI Components 

6.2.1 RPKI VC Component 

The deployment or use of a VC (local or remote) is required for the support of ROV. As of this writing, we 
are aware of three open-source implementations of VCs that are available. The demonstration build 
used two of these. 

A third open-source VC implementation is also available from Raytheon BBN Technologies. 

Organizations wishing to adopt ROV may wish to investigate the use of this tool, which is called Rpstir. 

Its software can be found at https://github.com/bgpsecuritv/rpstir . 

Organizations that deploy open-source VC software should be aware of the possibility that they may 
eventually be required to assume some responsibility for keeping the software updated and maintained. 

6.2.2 RPKI CA and Repository Components 

Address holders willing to use the hosted model for ROA creation and storage can depend on their RIR 
to provide these services for them. Organizations wishing to deploy their own delegated model for ROA 
creation, maintenance, and storage will need CAand repository software. As of this writing, we are 
aware of one open-source implementation of CA and RPKI repository software that is available. We 
were able to use this software successfully to set up a delegated model CA and repository. Flowever, it is 
not a turnkey product. Rather, its implementation requires a considerable staff 
investment. Organizations wishing to use the delegated model for RPKI to host their own CA and 
repository should be aware that, in order to do so, they will either have to develop their own software 
or they will need to take responsibility for maintaining and supporting the open-source implementation. 
We did not subject this demonstration implementation to stress, robustness, availability, or other 
testing that would typically be required before an organization would want to place it into operational 
use. 
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6.2.3 ROV-Capable Routers 

The commercial implementations of ROV-capable routers that we demonstrated are well documented, 
well supported, and can be used easily out of the box. See Section 7, Functional and Robustness Results, 
for details regarding their functionality. 

6.2.4 Lessons Learned 

■ One of the most important lessons learned from the implementation and testing of the RPKI 
technologies is to ensure that the most recent OS is installed on the router. Older versions of an 
OS may not have the latest capabilities. 

■ It is important to note that the default configuration for some routers is to exclude invalid 
prefixes from the routing table, whereas, for other routers, specific policy has to be defined to 
establish disposition for valid, invalid, and not found prefixes. Some routers presume that all 
local routes, including iBGP learned routes, default to valid, especially when community strings 
are not sent [RFC 8097] . An additional lesson learned worth mentioning is that some routers 
may be configured for one additional state of "unverified" via a policy statement to indicate the 
case in which a router did not perform ROV on the particular route. 

■ With the use of RPKI, BGP ROV results in BGP routes that are evaluated as either valid, invalid, 
or not found. While accepting the valid routes for usage is the default recommendation and 
non-controversial, organizations should use their local route selection policies for routes that 
are invalid or not found. Initially, organizations can simply log the fact that routes have been 
evaluated as invalid or not found, without changing the routes' behavior at all. This would be a 
risk-free method of initiating the adoption of RPKI ROV by monitoring how ROV would affect the 
routing if policies would be applied to the validation result. Flowever, no increased level of route 
origin assurance would result from this level of adoption either. Such an initial adoption 
period—during which all routes are evaluated; statistics are gathered regarding the number of 
valid, invalid, and not found routes; but no special action is taken for invalid or not found 
routes—could be helpful with respect to allowing organizations to determine the extent to 
which various potential policies that they may be considering using might affect routing. 

■ When configuring an RP, the trust anchor locator (TAL) of the five RIRs must be provided. In 
most VCs, four out of five TAL files are pre-loaded. The fifth TAL file, for ARIN, has to be 
downloaded. One should note that there are three TAL file formats: RFC 7730, RFC 6490, and 
RIPE NCC Validator format. It's important to be mindful of the TAL file format that the VC uses. 

■ On iBGP connections, we observed a slight increase in the number of BGP updates when the 
validation result was conveyed in iBGP using the extended community [RFC 8182] . The reason 
for this is that prefixes that originally could be packed into one update might not have been able 
to be packed anymore due to different validation results. Additionally, if selected updates 
changed the validation result, the router will resend the updates with the updated community 
string. In general, by turning on ROV, there will likely be a slight increase in the number of 
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updates sent. An otherwise stable route whose configuration state changes will be re-signaled 
with the new extended community as its validation state changes. 

Delegated Model 

■ Whether an address holder should use the hosted or delegated model for issuing ROAs depends 
on several factors. If the address holder is a large ISP that sub-allocates address space to various 
subscriber organizations, it may well determine that it will be to its benefit to stand up its own 
CA infrastructure and to deploy the delegated model. The hosted model is likely preferable for 
smaller address holders that will not be sub-allocating their address space to other organizations 
and that do not necessarily have the resources to deploy, configure, operate, and maintain their 
own CA infrastructure and RPKI repository - and do so in a way that assures its accessibility, 
robustness, and responsiveness. Regardless of the model used, all address holders should create 
ROAs for their addresses to enable network operators and RPs to be able to verify the origin of 
route advertisements that are sent out advertising the address holder's prefixes. 

■ The documentation for the RPKI.net toolkit, which implements the CA and repository, contains 
gaps. Moreover, we found that the RPKI.net toolkit would benefit from additional debugging 
tools and guidance. It is, at times, unclear how the agents are interacting with each other. 

During setup, and for learning purposes, it may be beneficial to run a traffic scanner to see what 
is being passed between hosts. Through trial and error, we identified the steps needed to 
complete installation and configuration. We provide these in Volume C of this Practice Guide. 

■ It should be possible to declare an ROA with a time-out. It did not appear that the RPKI.net tool 
could issue an ROA with an explicit time-out. 

7 Functional and Robustness Results 

We conducted a functional and robustness evaluation of the SIDR example implementation, as deployed 
in our laboratory, to verify that it worked as expected. The evaluation was intended to verify that the 
example implementation functioned as expected from several different perspectives: 

■ a resource holder (e.g., an ISP that sub-allocates the address space it holds and that provides 
addresses to its customers) setting up its own CA as a delegated RPKI participant and offering 
either a hosted model or a delegated model (or both) of RPKI support to its customers 

(i.e., obtaining CA certificates; creating EE certificates; creating, signing, and revoking ROAs; and 
uploading ROAs and other objects to the RPKI repository). 

■ an address holder protecting the addresses it holds by creating and managing ROAs for those 
addresses by using either the hosted or delegated model 

■ an RP operating a BGP router and performing ROV on all of the route prefix advertisements that 
it receives, to determine if they are valid, invalid, or not found, and applying configured policy 
based on the result 
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In all cases, the evaluation tested functionality using both IPv4 and IPv6 addresses. Both virtual and 
physical ROV-capable routers were used. Access to a live physical circuit was provided by CenturyLink. 
The circuit delivers full internet routes into the lab via live BGP peering and provides connectivity to the 
internet where the RIRs reside. 

Some testing was performed using live and interactive full internet routes, while other testing was 
performed using static data injected via a predefined test harness created by NIST. The test harness 
provides a BGP traffic generation and collection framework—BGPSEC-IO (BIO)^—as well as a mechanism 
for providing RPKI data by using an RPKI traffic generator, both part of the NIST BGP-SRx Software Suite 
[NIST BGP-SRxj . The harness environment was used to ensure that the test scenarios performed can be 
regenerated using carefully manufactured static data that are pre-populated and controlled via traffic 
generators and measurement tools. 

The VC used in both functional and robustness tests was the RIPE NCC RPKI Validator Version 2.24 . It 
was chosen because of its inherent flexibilities, including the ability to dynamically add local (white list) 
entries. 

Whereas the RPKI delegated model that was developed in-house was used for preliminary functional 
tests, all of the documented functional tests were done using the hosted model with locally added 
entries for ROA data. These entries were added via web interface/simplified local internet number 
resource management (SLURM) workload manager files in the case of the Harness test environment for 
RIPEv2. We were able to install RIPEv3 on Linux systems by using the binary RPM distribution. At the 
time of testing, RIPEv3 had some bugs that prevented us from using RIPEv3. One issue was the 
incapability of processing large SLURM files (25-percent coverage of routing table). This seems to be 
resolved in the latest binary version. An additional more pressing issue was that RIPEv3 does not 
recognize ROA data if no TAL file is configured. The Validator reports "no data" to the router. This issue 
has been reported and is expected to be resolved in a future release. 

Figure 7-1 depicts the test bed using the test harness (BGP traffic generation and collection framework 
[BGPSEC-IO]). Figure 7-2 depicts the test bed using live traffic. 

Note: The test bed using live traffic has a Palo Alto Next-Generation Firewall (PANW) that sits between 
the ISP and the internal environment to allow only the relevant traffic for this project. 
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1089 Figure 7-1 SIDR Testbed Using the Test Harness 
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1091 Figure 7-2 SIDR Testbed Using Live Traffic 
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7.1 Assumptions and Limitations 

This functional evaluation has the following limitations: 

■ It is not a comprehensive test of all security components, nor is it a red-team exercise. 

■ It cannot identify all weaknesses. 

■ The hardware components that were part of the demonstration build were typical of enterprise 
edge routers or small aggregation routers. 

■ The scaling tests that were performed included numbers of routers and peers typical of 
enterprise interconnectivity. In this context, we used routing tables of sizes similar to the full 
current internet routing table (approximately 700,000 routes). 

■ ISPs will require further testing, in terms of the number of routes, route changes, and sources of 
routes that are larger than the current global routing table to handle future expected growth. In 
addition, carriers will need to test geographically distributed validators as well as anycast- 
capable validators. Testing of the impact of timing issues will also be required. 

The functional evaluation also does not include the laboratory infrastructure security evaluation. It is 
assumed that its devices are hardened. Testing these devices would reveal only weaknesses in 
implementation that would not be relevant to those adopting this reference architecture. It is also 
important to note the need to harden the implementation if this Practice Guide is used by others, such 
as enterprise networking organizations or ISPs, as a roadmap for deployment. Though Section 4.4 and 
Section 4.5 describe NIST SP 800-53 controls addressed by the demonstrated capabilities, they do not 
list the full set of NIST SP 800-53 controls that apply to routers and routing systems. For example, issues 
such as signature validation and transfer protocol security must be addressed in any operational 
implementation. 

Section 11 of the RPKI-to-router specification [RFC 6810] provides guidance regarding securing the 
protocol. The security considerations taken for our demonstration build (e.g. firewall rules) are 
documented in Volume C of this Practice Guide. 

7.2 Functional Test Requirements 

This section provides a summary of the functional requirements that were tested. A detailed table of 
functional test requirements and their corresponding tests is provided in Appendix E . 

7.2.1 ROV Functional Requirements 

The SIDR example implementation included a capability for BGP routers to perform ROV on all routes 
that they receive in BGP update messages. The router was capable of accurately establishing an initial 
validation state (valid, invalid, or not found) for a given route, and marking the route accordingly. The 
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router was also capable of accurately reevaluating that route's validation state after RPKI test data has 
been perturbed, re-marking the route (where applicable). Tests were performed for the following cases: 

■ routes received through eBGP and iBGP updates 

■ local static routes redistributed into BGP 

■ routes redistributed into BGP from an interior gateway protocol (IGP) 

■ routes redistributed into BGP from an iBGP 

■ router cache synchronization 

7.2.2 Delegated RPKI-Model Functional Requirements 

The SIDR example implementation included the capability for a resource holder to set up its own 
delegated CA, create its own repository, and offer a hosted service to its customers, including the ability 
to publish customer ROAs to its repository, delete customer ROAs from its repository, and have 
customer ROAs expire from its repository. The ROAs in this delegated CA repository were included in the 
RPKI data that RPs downloaded to their VCs, and VRPs derived from these ROAs were provided to RP 
routers via the RPKI-to-router protocol. 

7.3 Functional Test Findings 

Securing the routing system is an important task for the internet. While RPKI-based ROV does not claim 
to solve all inherent security issues with the use of the BGP routing protocol, it provides significant 
progress in helping resolve some of the issues surrounding BGP route hijacks. To verify the maturity and 
effectiveness of RPKI technology, numerous functionality tests were performed using the prototype 
implementation in the NCCoE lab. It is important to note that most issues encountered during functional 
tests were quickly resolved either by installing an updated router OS provided by a vendor or by setting 
up some optional configuration. 

Not all proposed test cases could be performed. The following are observations as a result of completing 
the functional tests: 

■ Not all RIRs currently support RRDP. 

■ RIRs implement the hosted model differently from each other. RIRs offer different user 
interfaces and also different RPKI support services. 

■ At the time of our testing, some interoperability issues were discovered in the iBGP signaling of 
the RPKI validation state between the various implementations under test. 

• During the course of the project, these issues were fixed in the affected implementations. 
Prerelease fixed versions of implementations were re-tested, and the interoperability 
issues were resolved. 
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• We expect that future full releases of the affected implementations will incorporate these 
fixes as well. 

■ Some versions of router software provided to this project did not correctly evaluate aggregated 
routes with the AS_SET attribute. Bug reports were filed with the implementors. 

• Users should verify support for proper BGP update validation in the presence of AS_SET. 

■ It was discovered that vendors evaluate locally learned routes (iBGP) differently. For example, 
some implementations default to valid for locally learned routes, while others determine the 
validity of locally learned routes via policy statements. 

■ There were router-to-VC interaction cases in which serial requests of delta ROA information did 
not completely conform with [RFC 6810] . Some VC versions do not support deltas in the RPKI-to- 
router protocol implementation [RFC 6810] . With the current scale of the deployed RPKI, it does 
not seem to produce issues; however, with a larger amount of RPKI coverage, this could cause 
unnecessary delays, especially for high poll frequencies. 

• Users should verify support for incremental updates in the RPKI-to-router protocol. 

7.4 Robustness Findings 

To test the impact of RPKI ROV on BGP routing convergence, we initially measured the convergence time 
of a router with one peer by using a full BGP table dump (approximately 700,000 BGP routes) without 
using ROV or any other policies to gather a baseline. We repeated the tests by adding RPKI origin 
validation by using 25-percent, 50-percent, 75-percent, and 100-percent ROA coverage. With no 
additional routing policies added, we observed an approximate increase of two percent to seven 
percent in convergence time across all tested platforms. 

8 Recommendations for Follow-on Activities 

8.1 Standards Initiatives 

In the course of our testing, the SIDR Project identified clarifications that might be made to some ROV 
and RPKI-related IETF specifications to potentially reduce ambiguity and improve interoperability. The 
IETF is progressing with such clarifying specifications. 

8.2 Future Demonstration Activities 

As was discussed earlier in this document, while ROV can help detect when an ISP or 
enterprise originates an update for an address that it is not authorized to announce (route hijacking), it 
is not able to detect when an AS makes an unauthorized modification of routing path information in a 
BGP update that it forwards. Such path modification attacks can deny access to internet services, detour 
traffic, misdeliver traffic to malicious endpoints, undermine protection systems, and cause routing 
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instability. The BGPsec protocol, which has recently been finalized within the IETF, is designed to protect 
against such path modification attacks. There are currently open-source prototype implementations of 
BGPsec available (e.g., NIST BGP-SRx Software Suite [NIST BGP-SRx] and the Parsons-enhanced BIRD 
implementation [Parsons BGPsec]) . As commercial implementations also become available, 
the NCCoE may consider initiating a project to build and demonstrate a BGPsec solution by using 
available protocols, products, and tools and publish a practice guide of lessons learned. 

RPKI-based BGP ROV and BGPsec implemented together have the potential to greatly increase the 
security of the BGP routing protocol, enabling an entity that receives a BGP update to validate that the 
AS that is listed as the originating AS is in fact the AS that originated the update, that the path to that AS 
that is in the update has not been modified in an unauthorized manner, and that the AS that originated 
the update was authorized to do so. 

BGPsec and ROV will work hand-in-hand to secure internet routing. A follow-on project to promote the 
adoption of BGPsec can be expected to increase the adoption of not only BGPsec, but also of ROV. 
Organizations that implement one can be expected to be eager to implement the other. 

8.3 Tool Development and Maintenance 

As was mentioned earlier, commercial routers that support ROV are available from multiple vendors, 
and these products are supported and maintained. Some other key components, such as VCs, 
publication point software, RPKI and CA tools, however, are not available with typical commercial 
support and backing. Ideally, commercial vendors will make this software available and support and 
maintain these products. 

Organizations wishing to use the delegated model for RPKI to host their own CA and repository should 
be aware that, in order to do so, they will have to either develop their own software or take 
responsibility for maintaining and supporting the open-source implementations. 

8.4 Infrastructure Testing 

Further testing on scalability and robustness issues with equipment and configurations with a scale 
similar to that of ISP networks should be considered. 

The security of the infrastructure used to deploy either a hosted or a delegated model will need to be 
tested. If carriers are using either model, the integrity and availability of RIR implementations will 
directly affect operation of the network. For example, a compromise of an RIR may lead to accepting 
incorrect routes or denying valid routes, or it may make the service unavailable. A DoS of the RIR may 
make updates of RPKI information unavailable. That may impact operations due to stale routing data. In 
addition, the security and availability of the various communication paths will need to be tested. This 
includes transferring RPKI data from a repository to a VC and from a VC to routers. 
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1222 8.5 Research Activities 

1223 Additional research is needed to determine how ROV-capable routers should best use the ROV 

1224 evaluation state in the route selection policy. As was mentioned earlier, researchers affiliated with NIST 

1225 and the IETF Working Group are investigating this question. Ideally, in the future, it will be possible to 

1226 easily configure various policies based on this research in ROV-capable routers. 
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Appendix A Application of Systems Security Engineering: 

Considerations for a Multidisciplinary Approach in 
the Engineering of Trustworthy Secure Systems 
(NIST SP 800-160) to the Secure Inter-Domain 
Routing Project 

The Secure Inter-Domain Routing (SIDR) project used NIST SP 800-160 within a framework for planning 
and conducting the Internet Routing Security Project. NIST SP 800-160 addresses the engineering-driven 
perspective and actions necessary to develop more defensible and survivable systems, inclusive of the 
machine, physical, and human components that compose the systems and the capabilities and services 
delivered by those systems. It starts with and builds upon a set of well-established international 
standards for systems and software engineering published by the International Organization for 
Standardization (ISO), the International Electrotechnical Commission (lEC), and the Institute of Electrical 
and Electronics Engineers (IEEE), and infuses systems security engineering methods, practices, and 
techniques into those systems and software engineering activities. The objective is to address security 
issues from a stakeholder's protection needs, concerns, and requirements, and to use established 
engineering processes to ensure that such needs, concerns, and requirements are addressed with 
appropriate fidelity and rigor, early, and in a sustainable manner throughout the life cycle of the system. 

The full integration of the systems security engineering discipline into the systems and software 
engineering discipline involves fundamental changes in the traditional ways of doing business within 
organizations—breaking down institutional barriers that, over time, have isolated security activities 
from the mainstream organizational management and technical processes, including, for example, the 
system development life cycle, acquisition/procurement, and enterprise architecture. The integration of 
these interdisciplinary activities requires the strong support of senior leaders and executives, and 
increased levels of communication among all stakeholders who have an interest in, or are affected by, 
the systems being developed or enhanced. 

The Internet Routing Security Project offered an opportunity to attempt to implement the principles 
underlying NIST SP 800-160 at the project level and to uncover any issues associated with project-level 
application of those principles. 

NIST SP 800-160 defines systems security engineering as part of a multidisciplinary systems engineering 
effort that: 

■ defines stakeholder security objectives, protection needs and concerns, security requirements, 
and associated validation methods 

■ defines system security requirements and associated verification methods 

■ develops security views and viewpoints of the system architecture and design 
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■ identifies and assesses vulnerabilities and susceptibility to life-cycle disruptions, hazards, and 
threats 

■ designs proactive and reactive security functions encompassed within a balanced strategy to 
control asset loss and associated loss consequences 

■ provides security considerations to inform systems engineering efforts with the objective to 
reduce errors, flaws, and weakness that may constitute security vulnerability leading to 
unacceptable asset loss and consequences 

■ identifies, quantifies, and evaluates the costs/benefits of security functions and considerations 
to inform analysis of alternatives, engineering trade-offs, and risk treatment® decisions 

■ performs system security analyses in support of decision making, risk management, and 
engineering trades 

■ demonstrates, through evidence-based reasoning, that security claims for the system have been 
satisfied 

■ provides evidence to substantiate claims for the trustworthiness of the system 

■ leverages multiple security and other specialties to address all feasible solutions to deliver a 
trustworthy, secure system 

The systems security engineering framework [ McEvillevl5] provides a conceptual view of the key 
contexts within which systems security engineering activities are conducted. The framework defines, 
bounds, and focuses the systems security engineering activities and tasks, both technical and non¬ 
technical, toward the achievement of stakeholder security objectives and presents a coherent, well- 
formed, evidence-based case that those objectives have been achieved. The framework is independent 
of the system type and the engineering or acquisition process model and is not to be interpreted as a 
sequence of flows or process steps, but rather as a set of interacting contexts, each with its own checks 
and balances. The systems security engineering framework emphasizes an integrated, holistic security 
perspective across all stages of the system life cycle and is applied to satisfy the milestone objectives of 
each life-cycle stage. The framework defines three contexts within which the systems security 
engineering activities are conducted. These are the problem context, the solution context, and the 
trustworthiness context. 

■ The probiem context defines the basis for an acceptably and adequately secure system, given 
the stakeholder's mission, capability, performance needs and concerns; the constraints imposed 
by stakeholder concerns related to cost, schedule, and risk and loss tolerance; and other 
constraints associated with life-cycle concepts for the system. 

■ The soiution context transforms the stakeholder security requirements into design requirements 
for the system; addresses all security architecture, design, and related aspects necessary to 
realize a system that satisfies those requirements; and produces sufficient evidence to 
demonstrate that those requirements have been satisfied to the degree possible, practicable, 
and acceptable to stakeholders. 
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1298 ■ The trustworthiness context is a decision-making context that provides an evidence-based 

1299 demonstration, through reasoning, that the system-of-interest is deemed trustworthy based 

1300 upon a set of claims derived from security objectives. 

1301 The systems security engineering framework also includes a closed-loop feedback for interactions 

1302 among and between the three framework contexts and the requisite system security analyses to 

1303 continuously identify and address variances as they are introduced into the engineering effort. The 

1304 feedback loop also helps achieve continuous process improvement for the system. 

1305 The SIDR Project was not the development of an operational system from scratch; rather, it was a 

1306 demonstration of a proof-of-concept platform composed on off-the-shelf components in order to 

1307 enable legacy systems to mitigate a defined set of cybersecurity threats. As such, many longer-term life 

1308 cycle processes (e.g., supply, human resource management, configuration management, and transition) 

1309 were primarily treated only in the Practice Guide in explaining how the platform might be used 

1310 operationally. The SIDR Project was planned and conducted in six phases: Initiation, Planning, Design, 

1311 Execution, Control, and Closing. 
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This project took the following (often recursive) steps in demonstrating the adaptation and use of NIST 
SP 800-160 to provide a project planning framework for the internet routing project at the National 
Cybersecurity Center of Excellence (NCCoE): 

■ Develop, state, and support the value proposition of the candidate project for the following 
overlapping Communities of Interest: 

• internet customers and users 

• internet service providers (ISPs) 

• routing product vendors 

• security product vendors 

■ Define the project requirements: 

• security objectives 

• security requirements 

• operational and design constraints 

• success determination and/or measurement 

• life-cycle security issues 

■ Describe, design, develop, and build the solution: 

• specification of required components and component characteristics 

• identify potential sources for components possessing the necessary characteristics 
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• define component interface and related performance requirements 

• solicit participation from sources of necessary components 

• enter into collaboration agreements with sources of necessary components 

• coordinate proof-of-concept architecture of composed security platform with collaborators 

• build and demonstrate the security platform to realize the security aspects of the solution 

• document the security platform's performance against project requirements as evidence 
for the security aspects of the solution 

■ Document project results: 

• demonstration of value proposition 

• demonstrated security improvements and residual risks 

• security platform build and integration details 

• how to use the security platform in a manner that achieves security objectives 

From an ISO/IEC/IEEE 15288:2015 life-cycle point of view, the Initiation phase of the project mapped to 
the following processes: 

■ Organization Project Enabling Process 

• Fiuman Resource Management 

■ Technical Management Process 

• Portfolio Management 

• Project Assessment and Control 

• Decision Management 

• Risk Management 

■ Technical Process 

• Business or Mission Analysis 

• Stakeholder Needs and Requirements Definition 

• Project Planning 

• System Requirements Definition 

• Architecture Definition Processes 

The Planning phase mapped to the following ISO/IEC/IEEE 15288:2015 life-cycle processes: 

■ Agreement Process 
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• Acquisition 

• Supply® 

■ Project Enabling Process 

• Risk Management 

• Human Resource Management 

• Quality Management 

• Knowledge Management 

■ Technical Management Process 

• Portfolio Management 

• Project Planning 

• Decision Management 

• Risk Management 

• Project Assessment and Control 

• Information Management 

• Measurement 

• Quality Assurance 

■ Technical Process 

• Business/Mission Analysis 

• Architecture Definition 

• Design Definition 

• System Analysis 

• Stakeholder Needs and Requirements Definition 

• System Requirements Definition 

• Implementation 

• Integration 

• Disposal 

The Design phase mapped to the following ISQ/IEC/IEEE 15288:2015 life-cycle processes: 

■ Project Enabling Process 

• Infrastructure Management 
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■ Technical Management Process 

• Portfolio Management 

• Project Planning 

• Decision Management 

• Configuration Management 

• Risk Management 

• Project Assessment and Control 

■ Technical Process 

• Business/Mission Analysis 

• Architecture Definition 

• Design Definition 

• System Analysis 

• Stakeholder Needs and Requirements Definition 

• Implementation 

• Integration 

• Verification 

The Execution phase mapped to the following ISO/IEC/IEEE 15288:2015 life-cycle processes: 

■ Agreement Process 

• Acquisition 

• Supply^ 

■ Project Enabling Process 

• Infrastructure Management 

• Quality Management 

• Knowledge Management 

■ Technical Management Process 

Project Assessment and Control 

• Configuration Management 

• Risk Management 

• Quality Assurance 
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■ Technical Process 

• Implementation 

• Integration 

• Verification 

The Control phase mapped to the following ISO/IEC/IEEE 15288:2015 life-cycle processes: 

■ Project Enabling Process 

• Infrastructure Management 

• Quality Management 

• Knowledge Management 

■ Technical Management Process 

• Project Assessment and Control 

• Information Management 

• Risk Management 

• Quality Assurance 

• Measurement 

■ Technical Process 

• Implementation 

• Integration 

• Verification 

The Closing phase mapped to the following ISQ/IEC/IEEE 15288:2015 life-cycle processes: 

■ Project Enabling Process 

• Infrastructure Management 

• Quality Management 

• Knowledge Management 

■ Technical Management Process 

• Project Planning 

• Information Management 

• Risk Management 

• Quality Assurance 
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• Measurement 

■ Technical Process 

Business or Mission Analysis 

• Implementation 

• Verification 

• Validation 

Keeping the feedback aspect of the context framework in mind, we mapped the primary focus of each 
project phase to each of the context's component elements as follows: 

■ The problem context: 

• determining life-cycle security concepts - Initiation 

• defining security objectives - Initiation 

• defining security requirements - Initiation and Planning 

• determining measures of success - Initiation and Planning 

■ The solution context: 

• defining the security aspects of the solution - Planning and Design 

• realizing the security aspects of the solution - Design and Execution 

• producing evidence for the security aspects of the solution - Execution and Control 

■ The trustworthiness context: 

• developing and maintaining the assurance case - Execution and Control 

• demonstrating that the assurance case is satisfied - Control and Closing 

Establishing the three contexts helped ensure that the engineering of the system was driven by a 
sufficiently complete understanding of the problem articulated in a set of stakeholder security 
objectives that reflected protection needs and security concerns—instead of by security solutions 
brought forth in the absence of consideration of the entire problem space and its associated constraints. 
Moreover, the approach resulted in explicit focus and a set of activities to demonstrate the worthiness 
of the solution in providing adequate security across competing and often conflicting constraints. 

One will note that as we moved from Problem to Solution to Analysis elements of the NIST SP 800-160 
framework, the need for adaptation increased. This was partly due to the fact that the output of an 
NCCoE project is a proof-of-concept demonstration, not a finished commercial product or government 
system. Organizations adapting NCCoE security platforms to their own environments will necessarily 
alter the demonstrated solution as needed to fit their own physical, operational, and contractual 
environments and will perform trustworthiness analyses in the context of their own risk acceptance 
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perceptions and constraints. In employing NIST SP 800-160 in this internet routing security project, the 
project engineers recognized that the candidate project involved the composition of several security- 
dedicated and security-purposed components in demonstrating upgrades to fielded systems while 
continuing to sustain day-to-day operations. Internet routing was accomplished using constantly 
evolving systems of systems. While the motivation for the proposed upgrades was reactive with respect 
to already realized attacks, the critical nature of internet routing systems is such that the planned 
security enhancements cannot be permitted to disrupt internet operations. Although current internet 
routing systems are generally built on operating systems that have both known and unknown security 
deficiencies, it is not currently practical to retire critical elements of the existing systems. Consequently, 
the security platform as demonstrated necessarily retained many existing vulnerabilities. Composition of 
the platform needed to be engineered in a manner that reduced the consequences of its flawed 
foundation. 

The systems security engineering aspects of the project also accommodated context sensitive 
considerations. Among these were the private-sector ownership, operation, and use of key internet 
components and the need to support widely varying stakeholder assessments of asset value and risk 
tolerance. Context sensitivity addressed multiple contexts and perceptions of return on investment. 

The following material explains the project life-cycle framework elements to which the NIST SP 800-160 
activities and tasks are mapped. 

When mapped against the NCCoE's project management framework, the activities and tasks took place 
at each of the following project phases as identified below. 

A.l Project Initiation 

Project initiation activities included initiation, concept, and business case review milestones. 

A.1.1 Initiation 

The initiation milestone involved identifying the business need, developing a Rough Order of Magnitude 
(ROM) cost and preliminary schedule, and identifying basic business and technical risks. The outcome of 
the Initiation phase was the decision to invest in a full business case analysis and preliminary project 
management plan. In the case of the SIDR Project, meeting the initiation milestone involved both NIST's 
Information Technology Laboratory (ITL) Advanced Network Technology Division (ANTD) staff and 
NCCoE staff interactions with standards activities (e.g., the Internet Engineering Task Force [IETF]) and 
industry organizations (e.g., the North American Network Operators Group [NANOG]) to identify the 
business need and basic business and technical risks. Subsequently, ANTD and the NCCoE staff 
developed ROM cost information and a preliminary schedule as part of a business case that was 
submitted to the NCCoE Governance Team for approval to proceed with the project. Note that the 
project did not move to the next phase until following NIST SP 800-160 guidelines (to the extent 
appropriate to this type of project) was added to the proposal. 
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The initiation activity was focused primarily on the following systems security engineering tasks 
described in Chapter 3 of NIST SP 800-160 : 

■ Define and Authorize the Security Aspects of the Project (PM-l): 

• Portfolio Management (PM-l.2) - Prioritize, select, and establish new business 
opportunities, ventures, or undertakings with consideration for security objectives and 
concerns. 

■ Human Resources Management (HR-1): 

• HR-1.1 - Identify systems security engineering skills needed based on current and expected 
projects. 

• HR-1.2 - Identify existing systems security engineering skills of personnel. 

■ Business and Mission Analysis (BA-1): 

• BA-1.1 - Identify stakeholders who will contribute to the identification and assessment of 
any mission, business, or operational problems or opportunities. 

• BA-1.2 - Review organizational problems and opportunities with respect to desired security 
objectives. 

• BA-1.3 - Define the security aspects of the business or mission analysis strategy. 

• BA-1.4 - Identify, plan for, and obtain access to enabling systems or services to support the 
security aspects of the business or mission analysis process. 

■ Stakeholder Protection Needs and Security Requirements Definition (SR-1): 

• SN-1.1 - Identify the stakeholders who have a security interest in the system throughout its 
life cycle. 

• SN-1.2 - Define the stakeholder protection needs and security requirements definition 
strategy. 

• SN-1.3 - Identify, plan for, and obtain access to enabling systems or services to support the 
security aspects of the stakeholder needs and requirements definition process. 

A.1.2 Concept 

The concept milestone identified the high-level business and functional requirements to develop the full 
business case analysis and preliminary Project Management Plan for the proposed project. The 
outcomes of the concept phase were the selection to the NCCoE cybersecurity project portfolio; 
approval of initial project cost, schedule, and performance baselines; and issuance of a Project Charter. 
Meeting the concept milestone involved a two-step process. First, an initiative proposal that included an 
industry assessment report, a Community of Interest report, and a concept milestone plan, was 
submitted to the NCCoE Governance Team. Following approval of the initiative proposal, a project risk 


NIST SP 1800-14B: Protecting the Integrity of Internet Routing 


58 




1546 

1547 

1548 

1549 

1550 

1551 

1552 

1553 

1554 

1555 

1556 

1557 

1558 

1559 

1560 

1561 

1562 

1563 

1564 

1565 

1566 

1567 

1568 

1569 

1570 

1571 

1572 

1573 

1574 

1575 

1576 

1577 

1578 


DRAFT 


assessment, technology research report, standards report, outreach/engagement plan, communications 
plan, and high-level project plan were submitted to the NCCoE Governance Team as parts of a business 
case with a needs assessment summary. 

The concept activity was focused primarily on the following systems security engineering tasks described 
in Chapter 3 of NIST SP 800-160 : 

■ Define and Authorize Security Aspects of the Project (PM-1): 

• Portfolio Management (PM-1.2) - Prioritize, select, and establish new business 
opportunities, ventures, or undertakings with consideration for security objectives and 
concerns. (Continued task from Initiation phase.) 

• Portfolio Management (PM-1.3) - Define the security aspects of projects, accountabilities, 
and authorities. 

• Portfolio Management (PM-1.4) - Identify the security aspects of projects, accountabilities, 
and authorities. 

■ Human Resources Management (HR-2.1) - Establish a plan for systems security engineering 
skills and development. 

■ Project Planning (PL-1.1) - Identify the security objectives and security constraints for the 
project. 

■ Business and Mission Analysis (BA-1) - This was essentially a continuation of the tasks from the 
continuation phase. 

■ Define the Security Aspects of the Problem Space (BA-2): 

• BA-2.1 - Analyze the problems and opportunities in the context of the security objectives 
and measures of success to be achieved. 

• BA-2.2 - Define the security aspects and considerations of the business or operational 
problem. 

■ Characterize the Security Aspects of the Solution Space (BA-3): 

• BA-3.1 - Define the security aspects of the preliminary operational concepts and other 
concepts in life-cycle stages. 

• BA-3.2 - Identify alternative solution classes that can achieve the security objectives within 
limitations, constraints, and other considerations. 

■ Define Stakeholder Protection Needs (SN-2): 

• SN-2.1 - Define the security context of use across all preliminary life-cycle concepts. 

• SN-2.2 - Identify stakeholder assets and asset classes. 

• SN-2.3 - Prioritize assets based on the adverse consequences of asset loss. 
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• SN-2.4 - Determine the susceptibility to adversity and uncertainty. 

• SN-2.5 - Identify stakeholder protection needs. 

• SN-2.6 - Prioritize and down-select the stakeholder protection needs. 

• SN-2.7 - Define the stakeholder protection needs and rationale. 

Develop the Security Aspects of Operational and Other Life-Cycle Concepts (SN-3): 

• SN3.1 - Define a representative set of scenarios to identify all required protection 
capabilities and security measures that correspond to anticipated operational and other 
life-cycle concepts. 

• SN-3.2 - Identify the security-relevant interaction between users and the system. 


1588 A.1.3 Business Case Review 

1589 A business case review was conducted by the NCCoE Governance Team after all requirements of the 

1590 Initiation phase were completed. The business case is a documented, structured proposal for a 

1591 cybersecurity project that is prepared to facilitate a selection decision for the proposed project by the 

1592 NCCoE Governance Team. The business case described the reasons and justification for the project, in 

1593 terms of cybersecurity performance, needs and/or problems, and expected benefits. It identified the 

1594 high-level requirements that needed to be satisfied and an analysis of proposed alternative solutions. 

1595 Based on the Governance Team's review of the business case and needs assessment, the project was 

1596 approved. 


1597 The business case review was focused primarily on the following systems security engineering tasks 

1598 described in Chapter 3 of NIST SP 800-160 : 


1599 ■ Define and Authorize the Security Aspects of Projects (PM-1): 


1600 • PM-1.8 - Authorize each project to commence execution with consideration of the security 

1601 aspects of project plans. 


1602 ■ Define the Security Aspects of the Problem or Opportunity Space (BA-2) - This was essentially a 

1603 continuation of the task from the concept phase. 


1604 A.2 Project Planning 

1605 Project planning activities include project management planning, project definition, team formation, and 

1606 requirements analysis milestones. 


1607 A.2.1 Project Management Plan 

1608 Supporting the planning milestone, the NCCoE completed development of a full project management 

1609 plan and schedule. The preliminary plan was developed as part of the business case, but it was reviewed 
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and refined in the course of weekly project review meetings. Project planning synthesized information 
from an analysis of capabilities requirements, resource requirements, risk information, and cost 
estimates, and developed a project baseline, a plan for laboratory setup and team formation, and a 
project management plan. It provided a structure and an implementation approach to ensure that the 
project could be successfully managed to completion. 

The project management planning activity was focused primarily on the following systems security 
engineering tasks described in Chapter 3 of NIST SP 800-160 : 

■ Prepare for Security Aspects of Acquisition (AQ-1): 

• AQ-1.1 - Define the security aspects for how acquisition will be conducted. 

■ Define and Authorize the Security Aspects of Projects (PM-1): 

• PM-1.5 - Identify and allocate resources for the achievement of the security aspects of 
project goals and objectives. 

• PM-1.7 - Specify the security aspects of project reporting requirements and review 
milestones that govern the execution of each project. 

■ Develop Systems Security Engineering Skills (HR-2) - This was a continuation of the task initiated 
in the concept development phase. 

■ Plan Security Quality Management (QM-1): 

• QM-1.1 - Establish security quality management objectives. 

• QM-1.2 - Establish security quality management policies, standards, and procedures. 

• QM-1.3 - Define responsibilities and authority for the implementation of security quality 
management. 

• QM-1.4 - Define security quality evaluation criteria and methods. 

QM-1.5 - Provide resources, data, and information for security quality management. 

■ Plan Security Knowledge Management (KM-1): 

• KM-1.1 - Define the security aspects of the knowledge management strategy. 

• KM-1.2 - Identify the security knowledge, skills, and knowledge assets to be managed. 

• KM-1.3 - Identify projects that can benefit from the application of the security knowledge, 
skills, and knowledge assets. 

■ Define the Security Aspects of the Problem (PL-1): 

• PL-1.4 - Identify the security activities and tasks of the work breakdown structure. 

■ Plan the Security Aspects of the Project and Technical Management (PL-2): 
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• PL-2.1 - Define and maintain the security aspects of a project schedule based on 
management and technical objectives and work estimates. 

• PL-2.2 - Define the security achievement criteria and major dependencies on external 
inputs and outputs for life-cycle-stage decision gates. 

• PL-2.3 - Define the security-related costs for the project and plan the budget informed by 
those projected costs. 

• PL-2.4 - Define the systems security engineering roles, responsibilities, accountabilities, 
and authorities. 

• PL-2.5 - Define the security aspects of infrastructure and services required. 

• PL-2.6 - Plan the security aspects of acquisition of materials and enabling systems and 
services supplied from outside the project. 

• PL-2.7 - Generate and communicate a plan for the project and technical management and 
execution, including reviews that address all security considerations. 

■ Plan for the Security Aspects of Project Assessment and Control (PA-1): 

• PA-1.1 - Define the security aspects of the project assessment strategy. 

• PA-1.2 - Define the security aspects of the project control strategy. 

■ Prepare for Decisions with Security Implications (DM-1): 

• DM-l.l - Define the security aspects of the decision management strategy. 

• DM-1.2 - Identify the security aspects of the circumstances and need for a decision. 

• DM-1.3 - Involve stakeholders with relevant security expertise in the decision making in 
order to draw on their experience and knowledge. 

■ Prepare for the Security Aspects of Configuration Management (CM-1): 

• CM-1.1 - Define the security aspects of a configuration management strategy. 

• CM-1.2 - Define the approach for the secure archive and retrieval for configuration items, 
configuration management artifacts, data, and information. 

■ Prepare for the Security Aspects of Information Management (IM-1): 

• IM-1.1 - Define the security aspects of the information management strategy. 

• IM-1.2 - Define protections for information items that will be managed. 

• IM-1.3 - Designate authorities and responsibilities for the security aspects of information 
management. 

• IM-1.4 - Define protections for specific information item content, formats, and structure. 

• IM-1.5 - Define the security aspects of information maintenance actions. 
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■ Prepare for Security Measurement (MS-1): 

• MS-1.1 - Define the security aspects of the measurement strategy. 

• MS-1.2 - Describe the characteristics of the organization that are relevant to security 
measurement. 

• MS-1.3 - Identify and prioritize the security-relevant information needs. 

• MS-1.4 - Select and specify measures that satisfy the security-relevant information needs. 

• MS-1.5 - Define procedures for the collection, analysis, access, and reporting of security¬ 
relevant data. 

• MS-1.6 - Define criteria for evaluating the security-relevant information items and the 
process used for the security aspects of measurement. 

• MS-1.7 - Identify, plan for, and obtain enabling systems or services to support the security 
aspects of measurement. 

■ Prepare for Security Quality Assurance (QA-1): 

• QA-1.1 - Define the security aspects of the quality assurance strategy. 

• QA-1.2 - Establish independence of security quality assurance from other life-cycle 
processes. 

■ Prepare for Stakeholder Protection Needs and Security Requirements Definition (SN-1) - 

• SN-1.1 - Identify the stakeholders who have a security interest in the system throughout its 
life cycle. 

• SN-1.2 - Define the stakeholder protection needs and security requirements definition 
strategy. 

• SN-1.3 - Identify, plan for, and obtain access to enabling systems or services to support the 
security aspects of the stakeholder needs and requirements definition process. 

■ Prepare for the Security Aspects of System Analysis (SA-1): 

• SA-1.1 - Identify the security aspects of the problem or question that requires system 
analysis. 

• SA-1.2 - Identify the stakeholders of the security aspects of system analysis. 

• SA-1.3 - Define the objectives, scope, level of fidelity, and level of assurance of the security 
aspects of system analysis. 

• SA-1.4 - Select the methods associated with the security aspects of system analysis. 

• SA-1.5 - Define the security aspects of the system analysis strategy. 
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• SA-1.6 - Identify, plan for, and obtain access to enabling systems or services to support the 
security aspects of the system analysis process. 

• SA-1.7 - Collect the data and inputs needed for the security aspects of system analysis. 

■ Prepare for the Security Aspects of Implementation (IP-1): 

• IP-1.1 - Develop the security aspects of the implementation strategy. 

• IP-1.2 - Identify constraints from the security aspects of the implementation strategy and 
technology on the system requirements, architecture, design, or implementation 
techniques. 

• IP-1.3 - Identify, plan for, and obtain access to enabling systems or services to support the 
security aspects of implementation. 

■ Prepare for the Security Aspects of Disposal (DS-1):^^ 

• DS-1.1 - Develop the security aspects of the disposal strategy. 

• DS-1.2 - Identify the system constraints resulting from the security aspects of disposal to 
be incorporated into the system requirements, architecture, and design. 

• DS-1.3 - Identify, plan for, and obtain the enabling systems or services to support the 
secure disposal of the system. 

• DS-1.4 - Specify secure storage criteria for the system if it is to be stored. 

• DS-1.5 - Identify and preclude terminated personnel or disposed system elements and 
materials from being returned to service. 

A.2.2 Project Definition 

The project definition milestone helped ensure that the requirements that are associated with the 
project result are specified as clearly as possible. This involved identifying the expectations that all of the 
involved parties had with regard to the project result. The project definition activity took the form of a 
Project Description that documented a common understanding as to what was included in, and 
excluded from, the project. The scope element of the Project Description dealt only with the boundaries 
of the project and did not address cost or schedule. Because changes in scope are inevitable as project 
requirements become more refined, contingencies for scope management were built into the project 
management plan to accept only those significant scope changes that were approved by the 
Governance Team. The Project Description was published on the NCCoE's website 
( https://nccoe.nist.gov/proiects/building-blocks/secure-inter-domain-routing ). 

The project definition activity was focused primarily on the following systems security engineering tasks 
described in Chapter 3 of NIST SP 800-160 : 

■ Prepare for Security Aspects of Supply (SP-1): 
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• SP-1.1 - Identify the security aspects of the acquirer's need for a product or service. 

• SP-1.2 - Define the security aspects of the supply strategy.^^ 

■ Develop System Security Engineering Skills (HR-2) - This was a continuation of the task initiated 
in the concept development and project plan development phases. 

■ Define the Security Aspects of the Project (PL-1): 

• PL-1.5 - Define and maintain the security aspects of processes that will be applied on the 
project. 

■ Plan the Security Aspects of the Project and Technical Management (PL-2): 

• PL-2.5 - Define the security aspects of infrastructure and services required. 

• PL-2.6 - Plan the security aspects of acquisition of materials and enabling systems and 
services supplied from outside the project. 

■ Analyze the Security Aspects of Decision Information (DM-2): 

• DM-2.1 - Select and declare the security aspects of the decision management strategy for 
each decision. 

• DM-2.2 - Determine the desired security outcomes and measurable security selection 
criteria. 

• DM-2.3 - Identify the security aspects of the trade space and alternatives. 

• DM-2.4 - Evaluate each alternative against the security evaluation criteria. 

■ Plan Security Risk Management (RM-1): 

• RM-1.1 - Define the security aspects of the risk management strategy. 

• RM-1.2 - Define and record the security context of the risk management process. 

■ Evaluate and Select Solution Classes (BA-4): 

• BA-4.1 - Assess each alternative solution class, taking into account the security objectives, 
limitations, constraints, and other relevant security considerations. 

• BA-4.2 - Select the preferred alternative solution class (or classes) based on the identified 
security objectives, trade space factors, and other criteria defined by the organization. 

■ Define Stakeholder Protection Needs (SN-2) - This was a continuation of the task from the 
concept phase. 

■ Develop the Security Aspects of Operational and Other Life-Cycle Concepts (SN-3.1): 

• SN-3.1 - Define a representative set of scenarios to identify all required protection 
capabilities and security measures that correspond to anticipated operational and other 
life-cycle concepts. 
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• SN-3.2 - Identify the security-relevant interaction between users and the system. 

■ Transform Stakeholder Protection Needs into Security Requirements (SN-4) - This was a 
continuation of the task from the concept phase. 

■ Prepare for System Security Requirements Definition (SR-1) - This is a continuation of the task 
from the concept phase. 

■ Define System Security Requirements (SR-2): 

• SR-2.1 - Define each security function that the system is required to perform. 

• SR-2.2 - Define system security requirements, security constraints on system 
requirements, and rationale. 

• SR-2.3 - Incorporate system security requirements and associated constraints into system 
requirements and define rationale. 

■ Analyze System Security in System Requirements (SR-3): 

• SR 3.1 - Analyze the complete set of system requirements in consideration of security 
concerns. 

• SR 3.2 - Define security-driven performance and assurance measures that enable the 
assessment of technical achievement. 

• SR 3.3 - Provide the analyzed system security requirements and security-driven constraints 
to applicable stakeholders for review. 

• SR 3.4 - Resolve system security requirements and security-driven constraints issues. 

■ Prepare for Architecture Definition from the Security Viewpoint (AR-1) - This a continuation of 
the activity from the Initiation phase. 

■ Develop Security Aspects of the Architecture (AR-2): 

• AR-2.1 - Define the concept of secure function for the system at the architecture level. 

• AR-2.2 - Select, adapt, or develop the security viewpoints and model kinds based on 
stakeholder security concerns. 

• AR-2.3 - Identify the security architecture frameworks to be used in developing the 
security models and security views of the system architecture. 

• AR-2.4 - Record the rationale for the selection of architecture frameworks that address 
security concerns, security viewpoints, and security model types. 

■ Develop Security Models and Security Views of Candidate Architectures (AR-3): 

• AR-3.1 - Define the security context and boundaries of the system in terms of interfaces, 
interconnections, and interactions with external entities. 
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• AR-3.2 - Identify architectural entities and relationships between entities that address key 
stakeholder security concerns and system security requirements. 

• AR-3.3 - Allocate security concepts, properties, characteristics, behavior, functions, or 
constraints to architectural entities. 

• AR-3.4 - Select, adapt, or develop security models of the candidate architectures. 

• AR-3.5 - Compose views in accordance with security viewpoints to express how the 
architecture addresses stakeholder security concerns and meets stakeholder and system 
security requirements. 

• AR-3.6 - Harmonize the security models and security views with each other and with the 
concept of secure function. 

■ Select Candidate Architecture (AR-5): 

• AR-5.1 - Assess each candidate architecture against the security requirements and 
security-related constraints. 

• AR-5.2 - Assess each candidate architecture against stakeholder security concerns using 
evaluation criteria. 

• AR-5.3 - Select the preferred architecture(s) and capture key security decisions and 
rationale for those decisions. 

• AR-5.4 - Establish the security aspects of the architecture baseline of the selected 
architecture. 

■ Prepare for Security Design Definition (DE-1): 

• DE-1.1 - Apply the concept of secure function for the system at the design level. 

• DE-1.2 - Determine the security technologies required for each system element composing 
the system. 

• DE-1.3 - Determine the types of security design characteristics. 

• DE-1.4 - Define the principles for secure evolution of the system design. 

• DE-1.5 - Define the security aspects of the design definition strategy. 

• DE-1.6 - Identify, plan for, and obtain access to enabling systems or services to support the 
security aspects of the design definition process. 

■ Establish Security Design Characteristics and Enablers for Each System Element (DE-2): 

• DE-2.1 - Allocate system security requirements to system elements. 

• DE-2.2 - Transform security architectural characteristics into security design 
characteristics. 

• DE-2.3 - Define the necessary security design enablers. 
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• DE-2.4 - Examine security design alternatives. 

• DE-2.5 - Refine or define the security interfaces between the system elements and with 
external entities. 

• DE-2.6 - Develop the security design artifacts. 

■ Assess the Alternatives for Obtaining Security-Relevant System Elements (DE-3): 

• DE-3.1 - Identify security-relevant non-developmental items (NDI) that may be considered 
for use. 

• DE-3.2 - Assess each candidate NDI and new design alternative against the criteria 
developed from expected security design characteristics or system element security 
requirements to determine suitability for the intended application. 

• DE-3.3 - Determine the preferred alternative among candidate NDI solutions and new 
design alternatives for a system element. 

■ Prepare for the Security Aspects of Implementation (IP-1) - This is a continuation of the task 
from the project management planning phase. 

■ Prepare for the Security Aspects of Integration (IN-1): 

• IN-1.1 - Identify and define checkpoints for the trustworthy secure operation of the 
assembled interfaces and selected system functions. 

• IN-1.3 - Identify, plan for, and obtain access to enabling systems or services to support the 
security aspects of integration. 

• IN-1.4 - Identify the constraints resulting from the security aspects of integration to be 
incorporated into the system requirements, architecture, or design. 

A.2.3 Team Formation 

During the form collaborative team milestone, the NCCoE initiated a Federal Register Notice (FRN) 
process to announce the project and to request Letters of Interest (LOI) from organizations desiring to 
participate in the project, linked the Project Description on the NCCoE's public website to the FRN, and 
worked with the NIST Technology Partnerships Office (TPO) to create the Cooperative Research and 
Development Agreements (CRADAs) needed to support the project. A CRADA is a written agreement 
between a private company and a government agency to work together on a project. In order to 
formally accept CRADA collaborators, we needed to receive LOIs from potential collaborators. LOIs were 
reviewed for consistency with the project requirements as stated in the FRN, and the NCCoE project 
staff supported TPO negotiation of CRADAs with interested organizations. Once a CRADA was signed, 
the organizations that had entered into the agreement became part of the project team. Outcomes of 
this milestone were a published FRN, signed CRADAs, and a roster of collaborators. 
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The team formation activity was focused primarily on the following systems security engineering tasks 
described in Chapter 3 of NIST SP 800-160 : 

■ Prepare for Security Aspects of the Acquisition (AQ-l):^"* 

• AQ-1.2 - Prepare a request for a product or service that includes the security 
requirements. 

■ Advertise the Acquisition and Select the Supplier to Conform with the Security Aspects of the 
Acquisition (AQ-2): 

• AQ-2.1 - Communicate the request for a product or service to potential suppliers 
consistent with security requirements. 

• AQ-2.2 - Select one or more suppliers that meet the security criteria. 

■ Establish and Maintain the Security Aspects of Agreements (AQ-3):^® 

• AQ-3.1 - Develop an agreement with the supplier to satisfy the security aspects of 
acquiring the product or service and supplier acceptance criteria. 

• AQ-3.2 - Identify and evaluate the security impact of necessary changes to the agreement. 

• AQ-3.3 - Negotiate and institute changes to the agreement with the supplier to address 
identified security impacts. 

■ Prepare for Security Aspects of Supply (SP-1): 

• SP-1.1 - Identify the security aspects of the acquirer's need for a product or service. 

■ Response to a Solicitation (SP-2): 

• SP-2.1 - Evaluate a request for a product or service with respect to the feasibility of 
satisfying the security criteria. 

SP-2.2 - Prepare a response that satisfies the security criteria expressed in the solicitation. 

■ Establish and Maintain the Security Aspects of Agreements (SP-3):^® 

• SP-3.1 - Develop an agreement with the acquirer to satisfy the security aspects of the 
product or service and security acceptance criteria. 

• SP-3.2 - Identify and evaluate the security impact of necessary changes to the agreement. 

• SP-3.3 - Negotiate and institute changes to the agreement with the acquirer to address 
identified security impacts. 

■ Acquire and Provide Systems Security Engineering Skills to Projects (HR-3): 

• HR-3.1 - Qbtain qualified systems security engineering personnel to meet project needs. 

• HR-3.2 - Maintain and manage the pool of skilled systems security engineering personnel 
to staff ongoing projects. 
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• HR-3.3 - Make personnel assignments based on the specific systems security engineering 
needs of the project and staff development needs. 

Define the Security Aspects of the Project (PL-1): 

• PL-1.2 - Define the security aspects of the project scope as established in agreements. 

Manage System Security Requirements (SR-4): 

• SR-4.1 - Obtain explicit agreement on the system security requirements and security- 
driven constraints. 

• SR-4.2 - Maintain traceability of system security requirements and security-driven 
constraints. 

• SR-4.3 - Provide security-relevant information items required for systems requirements 
definition to baselines. 

Perform the Security Aspects of Implementation (IP-2): 

• IP-2.1 - Realize or adapt system elements in accordance with the security aspects of the 
implementation strategy, defined implementation procedures, and security-driven 
constraints. 

• IP-2.2 - Develop initial training materials for users for operation, sustainment, and support. 

• IP-2.3 - Securely package and store system elements. 

• IP-2.4 - Record evidence that system elements meet the system security requirements. 

Prepare for the Security Aspects of Integration (IN-1): 

• IN-1.2 - Develop the security aspects of the integration strategy (continued from project 
definition phase). 

Perform the Security Aspects of Integration (IN-2): 

• IN-2.1 - Obtain implemented system elements in accordance with security criteria and 
requirements established in agreements and schedules. 


1923 A.2.4 Requirements Analysis 

1924 During the requirements analysis milestone, the cybersecurity project requirements that were 

1925 documented during the earlier phases were validated by project team members and were further 

1926 analyzed and decomposed into functional and non-functional requirements that define the 

1927 cybersecurity project in more detail with regard to inputs, processes, outputs, and interfaces. A logical 

1928 and physical depiction of the data entities, relationships, and attributes of the system/application were 

1929 also created. During the requirements analysis milestone, the initial strategy for testing and 

1930 implementation was considered. Updates were made, as required, to the Project Description and 

1931 Project Plan. 
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The requirements analysis activity was focused primarily on the following systems security engineering 
tasks described in Chapter 3 of NIST SP 800-160 : 

■ Prepare for the Security Aspects of Supply: 

• SP-1.2 - Define the security aspects of the supply strategy^^ (continued from project 
definition). 

■ Define and Authorize the Security Aspects of Projects:^® 

• PM-1.6 - Identify the security aspects of any multi-project interfaces and dependencies to 
be managed or supported by each project. 

■ Evaluate the Security Aspects of the Portfolio of Projects (PIVI-2): 

PM-2.1 - Evaluate the security aspects of projects to confirm ongoing viability. 

• PM-2.2 - Continue or redirect projects that are satisfactorily progressing or can be 
expected to progress satisfactorily by appropriate redirection in consideration of project 
security aspects. 

■ Assess Security Quality Management (QM-2): 

• QM-2.1 - Obtain and analyze quality assurance evaluation results in accordance with the 
defined security quality evaluation criteria. 

• QM-2.2 - Assess customer security quality satisfaction. 

• QM-2.3 - Conduct periodic reviews of project quality assurance activities for compliance 
with the security quality management policies, standards, and procedures. 

• QM-2.4 - Monitor the status of security quality improvements on processes, products, and 
services. 

■ Activate the Security Aspects of the Project (PL-3): 

• PL-3.1 - Obtain authorization for the security aspects of the project. 

• PL-3.2 - Submit requests and obtain commitments for the resources required to perform 
the security aspects of the project. 

• PL-3.3 - Implement the security aspects of the project plan. 

■ Assess the Security Aspects of the Project (PA-2): 

• PA-2.1 - Assess the alignment of the security aspects of project objectives and plans with 
the project context. 

• PA-2.2 - Assess the security aspects of the management and technical plans against 
objectives to determine adequacy and feasibility. 
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• PA-2.3 - Assess the security aspects of the project and its technical status against 
appropriate plans to determine actual and projected cost, schedule, and performance 
variances. 

• PA-2.4 - Assess the adequacy of the security roles, responsibilities, accountabilities, and 
authorities associated with the project. 

• PA-2.5 - Assess the adequacy and availability of resources allocated to the security aspects 
of the project. 

■ Prepare for Decisions with Security Implications (DM-1): 

• DM-1.3 - Involve stakeholders with relevant security expertise in the decision making in 
order to draw on their experience and knowledge (continued from project management 
planning). 

■ Manage the Security Aspects of the Risk Profile (RM-2):^® 

• RM2.1 - Define and record the security risk thresholds and conditions under which a level 
of risk may be accepted. 

• RM-2.2 - Establish and maintain the security aspects of the risk profile. 

• RM-2.3 - Provide the security aspects of the risk profile to stakeholders based on their 
needs. 

■ Perform Process Security Evaluations (QA-3): 

• QA-3.1 - Evaluate project life-cycle processes for conformance to established security 
criteria, contracts, standards, and regulations. 

• QA-3.2 - Evaluate tools and environments that support or automate the process for 
conformance to established security criteria, contracts, standards, and regulations. 

• QA-3.3 - Evaluate supplier processes for conformance to process security requirements. 

■ Analyze Stakeholder Security Requirements (SN-5): 

• SN-5.1 - Analyze the complete set of stakeholder security requirements. 

• SN-5.2 - Define critical security-relevant performance and assurance measures that enable 
the assessment of technical achievement. 

• SN-5.3 - Validate that stakeholder protection needs and expectations have been 
adequately captured and expressed by the analyzed security requirements. 

• SN-5.4 - Resolve stakeholder security requirements issues. 

■ Analyze System Security in System Requirements (SR-3) - Continued from project definition. 

■ Establish Security Design Characteristics and Enablers for Each System Element (DE-1) - 
Continued from project definition. 
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■ Assess the Alternatives for Obtaining Security-Relevant System Elements (DE-3) - Continued 
from project definition. 

■ Perform the Security Aspects of System Analysis (SA-2): 

• SA-2.1 - Identify and validate the assumptions associated with the security aspects of 
system analysis. 

• SA-2.2 - Apply the selected security analysis methods to perform the security aspects of 
required system analysis. 

• SA-2.3 - Review the security aspects of the system analysis results for quality and validity. 

• SA-2.4 - Establish conclusions, recommendations, and rationale based on the results of the 
security aspects of system analysis. 

• SA-2.5 - Record the results of the security aspects of system analysis. 

A.3 Build Design 

Build design activities include design drafting, coordinating and refining the design to produce a final 
design, and conducting a successful detailed design review. 

A.3.1 Draft Design 

The draft design milestone sought to develop detailed specifications that emphasize the physical 
solution to cybersecurity needs. The system requirements and logical description of the entities, 
relationships, and attributes of the data that were documented during the requirements analysis phase 
were further refined and allocated in the Project Description, cybersecurity build design documentation, 
and design material included in NIST SP 1800-14B and NIST SP 1800-14C that were organized in a way 
suitable for implementation within the constraints of the project's physical environment. 

The draft design activity was focused primarily on the following systems security engineering tasks 
described in Chapter 3 of NIST SP 800-160 : 

■ Establish the Secure Infrastructure (IF-1): 

IF-1.1 - Define the infrastructure security requirements. 

• IF-1.2 - Identify, obtain, and provide the infrastructure resources and services that provide 
security functions and services that are adequate to securely implement and support 
projects. 

■ Make and Manage Security Decisions (DM-3): 

• DM-3.1 - Determine preferred alternative for each security-informed and security-based 
decision. 
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• DM-3.2 - Record the security-informed or security-based resolution, decision rationale, 
and assumptions. 

• DM-3.3 - Record, track, evaluate, and report the security aspects of security-informed and 
security- based decisions. 

■ Analyze Security Risk (RM-3): 

• RM-3.1 - Identify security risks in the categories described in the security risk management 
context. 

• RM-3.2 - Estimate the likelihood of occurrence and consequences of each identified 
security risk. 

• RM-3.3 - Evaluate each security risk against its security risk thresholds. 

• RM-3.4 - Define risk treatment strategies and measures for each security risk that does not 
meet its security risk threshold. 

■ Treat Security Risk (RM-4): 

• RM-4.1 - Identify recommended alternatives for security risk treatment. 

• RM-4.2 - Implement the security risk treatment alternatives selected by stakeholders. 

• RM-4.3 - Identify and monitor those security risks accepted by stakeholders to determine if 
any future risk treatment actions are necessary. 

• RM-4.4 - Coordinate management action for the identified security risk treatments. 

■ Perform the Security Aspects of Configuration Identification (CM-2): 

• CM-2.1 - Identify the security aspects of system elements and information items that are 
configuration items. 

• CM-2.2 - Identify the security aspects of the hierarchy and structure of system information. 

• CM-2.3 - Establish the security nomenclature for system, system element, and information 
item identifiers. 

• CM-2.4 - Define the security aspects of baseline identification throughout the system life 
cycle. 

• CM-2.5 - Obtain acquirer and supplier agreement for security aspects to establish a 
baseline. 

■ Develop the Security Aspects of Operational and Other Life-Cycle Concepts (SN-3) - Continued 
from project definition activity. 

■ Develop Security Models and Security Views of Candidate Architectures (AR-3) - Continued from 
project definition activity. 
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■ Assess the Alternatives for Obtaining Security-Relevant System Elements (DE-2) - Continued 
from project definition activity. 

■ Manage the Security Design (DE-4): 

• DE-4.1 - Map the security design characteristics to the system elements. 

• DE-4.2 - Capture the security design and rationale. 

• DE-4.3 - Maintain traceability of the security aspects of the system design. 

• DE-4.4 - Provide security-relevant information items required for the system design 
definition to baselines. 

■ Manage the Security Aspects of System Analysis (SA-3): 

• SA-3.1 - Maintain traceability of the security aspects of the system analysis results. 

• SA-3.2 - Provide security-relevant system analysis information items that have been 
selected for baselines. 

■ Perform the Security Aspects of Implementation (IP-2) - Continued from team formation 
activity. 

■ Perform the Security Aspects of Integration (IN-2): 

• IN-2.1 - Obtain implemented system elements in accordance with security criteria and 
requirements established in agreements and schedules (continued from team formation 
activity). 

• IN-2.2 - Assemble the implemented systems elements to achieve secure configurations. 

• IN-2.3 - Perform checks of the security characteristics of interfaces, functional behavior, 
and behavior across interconnections. 

■ Prepare for the Security Aspects of Verification (VE-1): 

• VE-1.1 - Identify the security aspects within the verification scope and corresponding 
security-focused verification actions. 

• VE-1.2 - Identify the constraints that can potentially limit the feasibility of the security- 
focused verification actions. 

• VE-1.3 - Select the appropriate methods or techniques for the security aspects of 
verification and the associated security criteria for each security-focused verification 
action. 

• VE-1.4 - Define the security aspects of the verification strategy. 

• VE-1.5 - Identify the system constraints resulting from the security aspects of the 
verification strategy to be incorporated into the system requirements, architecture, or 
design. 
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• VE-1.6 - Identify, plan for, and obtain access to enabling systems or services to support the 
security aspects of verification. 

A.3.2 Final Design 

During the final design milestone, the final architecture diagram and build design were completed and 
documented. The outcome of the design milestone was the successful completion of the detailed design 
reviews with the NCCoE Governance Team. 

The final design activity was focused primarily on the following systems security engineering tasks 
described in Chapter 3 of NIST SP 800-160 : 

■ Establish the Secure Infrastructure (IF-1): 

• IF-1.1 - Define the infrastructure security requirements (continued from design drafting 
activity). 

■ Make and Manage Security Decisions (DM-3) - Continued from design drafting activity. 

■ Analyze Security Risk (RM-3) - Continued from design drafting activity. 

■ Treat Security Risk (RM-4) - Continued from design drafting activity. 

■ Perform the Security Aspects of Configuration Identification (CM-2) - Continued from design 
drafting activity. 

■ Relate Security Views of the Architecture to the Design (AR-4): 

• AR-4.1 - Identify the security-relevant system elements that relate to architectural entities 
and the nature of these relationships. 

• AR-4.2 - Define the security interfaces, interconnections, and interactions between the 
system elements and with external entities. 

• AR-4.3 - Allocate system security requirements to architectural entities and system 
elements. 

• AR-4.4 - Map security-relevant system elements and architectural entities to security 
design characteristics. 

• AR-4.5 - Define the security design principles for the system design and evolution that 
reflect the concept of secure function. 

■ Select Candidate Architecture (AR-5): 

• AR-5.1 - Assess each candidate architecture against the security requirements and 
security-related constraints. 

• AR-5.2 - Assess each candidate architecture against stakeholder security concerns by using 
evaluation criteria. 
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• AR-5.3 - Select the preferred architecture(s) and capture key security decisions and 
rationale for those decisions. 

• AR-5.4 - Establish the security aspects of the architecture baseline of the selected 
architecture. 

■ Manage the Security View of the Selected Architecture (AR-6): 

• AR-6.1 - Formalize the security aspects of the architecture governance approach and 
specify security governance-related roles and responsibilities, accountabilities, and 
authorities. 

• AR-6.2 - Obtain explicit acceptance of the security aspects of the architecture by 
stakeholders. 

• AR-6.3 - Maintain concordance and completeness of the security architectural entities and 
their security-related architectural characteristics. 

• AR-6.4 - Organize, assess, and control the evolution of the security models and security 
views of the architecture. 

• AR-6.5 - Maintain the security aspects of the architecture definition and evaluation 
strategy. 

• AR-6.6 - Maintain traceability of the security aspects of the architecture. 

• AR-6.7 - Provide security-relevant information items required for architecture definition to 
baselines. 

■ Manage the Security Aspects of System Analysis (SA-3) - Continued from design drafting activity. 

■ Perform the Security Aspects of Implementation (IP-2) - Continued from design drafting activity. 

■ Perform the Security Aspects of Integration (IN-2) - Continued from design drafting activity. 

■ Prepare for the Security Aspects of Verification (VE-1) - Continued from design drafting activity. 

A.3.3 Detailed Design Review 

The detailed design review is a formal inspection of the high-level architectural design of the project's 
cybersecurity solution and its internal and external interfaces. Following consensus by the project team 
regarding the build design, the final high-level architecture and build design were provided to the NCCoE 
Governance Team. This provided the NCCoE Governance Team with information necessary for a design 
review to achieve agreement and confidence that the design satisfied the functional and non-functional 
requirements and was in conformance with the solution architecture. Overall project status, proposed 
technical solutions, evolving software products, associated documentation, and capacity estimates were 
reviewed to determine completeness and consistency with design standards, to raise and resolve any 
technical and/or project-related issues, and to identify and mitigate project, technical, security, and/or 
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business risks affecting continued detailed design and subsequent development, testing, 
implementation, and operations and maintenance activities. 

The detailed design review activity was focused primarily on the following systems security engineering 
tasks described in Chapter 3 of NIST SP 800-160 : 

■ Evaluate the Security Aspects of the Portfolio of Projects (PIVI-2): 

• PM-2.1 - Evaluate the security aspects of projects to confirm ongoing viability. 

• PM-2.2 - Continue or redirect projects that are satisfactorily progressing or can be 
expected to progress satisfactorily by appropriate redirection in consideration of project 
security aspects. 

■ Activate the Security Aspects of the Project (PL-3): 

• PL-3.1 - Obtain authorization for the security aspects of the project. 

• PL-3.2 - Submit requests and obtain commitments for the resources required to perform 
the security aspects of the project. 

• PL-3.3 - Implement the security aspects of the project plan. 

■ Assess the Security Aspects of the Project (PA-2): 

• PA-2.1 - Assess the alignment of the security aspects of project objectives and plans with 
the project context. 

• PA-2.2 - Assess the security aspects of the management and technical plans against 
objectives to determine adequacy and feasibility. 

• PA-2.3 - Assess the security aspects of the project and its technical status against 
appropriate plans to determine actual and projected cost, schedule, and performance 
variances. 

• PA-2.4 - Assess the adequacy of the security roles, responsibilities, accountabilities, and 
authorities associated with the project. 

• PA-2.5 - Assess the adequacy and availability of resources allocated to the security aspects 
of the project. 

• PA-2.6 - Assess progress using measured security achievement and milestone completion. 

• PA-2.7 - Conduct required management and technical reviews, audits, and inspections with 
full consideration for the security aspects of the project. 

• PA-2.9 - Analyze security measurement results and make recommendations. 

• PA-2.10 - Record and provide security status and security findings from the assessment 
tasks. 
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■ Manage the Security View of the Selected Architecture (AR-6) - Continued from final design 
activity. 

■ Perform the Security Aspects of System Analysis (SA-2): 

• SA-2.1 - Identify and validate the assumptions associated with the security aspects of 
system analysis. 

• SA-2.2 - Apply the selected security analysis methods to perform the security aspects of 
required system analysis. 

• SA-2.3 - Review the security aspects of the system analysis results for quality and validity. 

• SA-2.4 - Establish conclusions, recommendations, and rationale based on the results of the 
security aspects of system analysis. 

• SA-2.5 - Record the results of the security aspects of system analysis. 

■ Perform Security-Focused Verification (VE-2): 

• Define the security aspects of the verification procedures, each supporting a security- 
focused verification action. 

A.4 Build Execution 

During the build milestone, the project team transformed any specifications for software harnesses 
(glue code) identified and documented in the detailed design phase into machine-executable form and 
ensured that all of the individual components of the SIDR solution functioned correctly and interfaced 
properly with other components within the system/application. System hardware, networking and 
telecommunications equipment, and commercial off-the-shelf / government off-the-shelf software were 
acquired and configured (see Section 4.5) . 

The build activity was focused primarily on the following systems security engineering tasks described in 
Chapter 3 of NIST SP 800-160 : 

■ Monitor the Security Aspects of Agreements (AQ-4):^^ 

• AQ-4.1 - Assess the execution of the security aspects of the agreement. 

• AQ-4.2 - Provide data needed by the supplier in a secure manner in order to achieve timely 
resolution of issues. 

■ Accept Products and Services (AQ-5): 

AQ-5.1 - Confirm that the delivered product or service complies with the security aspects 
of the agreement. 

• AQ-5.2 - Accept the product or service from the supplier or other party, as directed by the 
security criteria in the agreement. 
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■ Execute the Security Aspects of Agreements (SP-4):^^ 

• SP-4.1 - Execute the security aspects of the agreement according to the engineering 
project plans. 

• SP-4.2 - Assess the execution of the security aspects of the agreement. 

■ Deliver and Support the Security Aspects of Products and Services (SP-5): 

• SP-5.1 - Deliver the product or service in accordance with the security aspects and 
considerations. 

• SP-5.2 - Provide security assistance to the acquirer as stated in the agreement. 

• SP-5.3 - Transfer the responsibility for the product or service to the acquirer or other party, 
as directed by the security aspects and considerations in the agreement. 

■ Establish the Secure Infrastructure (IF-1): 

• IF-1.2 - Identify, obtain, and provide the infrastructure resources and services that provide 
security functions and services that are adequate to securely implement and support 
projects. 

■ Maintain the Secure Infrastructure (IF-2): 

• IF-2.1 - Evaluate the degree to which delivered infrastructure resources satisfy project 
protection needs. 

• IF-2.2 - Identify and provide security improvements or changes to the infrastructure 
resources as the project requirements change. 

■ Perform Security Quality Management Corrective and Preventive Actions (QM-3): 

• QM-3.1 - Plan corrective actions when security quality management objectives are not 
achieved. 

• QM-3.2 - Plan preventive actions when there is a sufficient risk that security quality 
management objectives will not be achieved. 

• QM-3.3 - Monitor security quality management corrective and preventive actions to 
completion and inform relevant stakeholders. 

■ Manage Security Knowledge, Skills, and Knowledge Assets (KM-4): 

• KM-4.1 - Maintain security knowledge, skills, and knowledge assets. 

• KM-4.2 - Monitor and record the use of security knowledge, skills, and knowledge assets. 

• KM-4.3 - Periodically reassess the currency of the security aspects of technology and 
market needs of the security knowledge assets. 

■ Assess the Security Aspects of the Project (PA-2): 
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• PA-2.9 - Analyze security measurement results and make recommendations (continued 
from detailed design review). 

■ Control the Security Aspects of the Project (PA-3): 

• PA-3.1 - Initiate the actions needed to address identified security issues. 

• PA-3.2 - Initiate the security aspects of necessary project replanning. 

• PA-3.3 - Initiate change actions when there is a contractual change to cost, time, or quality 
due to the security impact of an acquirer or supplier request. 

• PA-3.4 - Recommend the project to proceed toward the next milestone or event, if 
justified, based on the achievement of security objectives and performance measures. 

■ Monitor Security Risks (RM-5): 

• RM-5.1 - Continually monitor all risks and the security risk management context for 
changes and evaluate the security risks when their state has changed. 

• RM-5.2 - Implement and monitor measures to evaluate the effectiveness of security risk 
treatment. 

• RM-5.3 - Monitor, on an ongoing basis, the emergence of new security risks and sources of 
risk throughout the life cycle. 

■ Perform Security Configuration Change Management (CM-3): 

• CM-3.1 - Identify security aspects of requests for change and requests for variance, to 
identify any security aspects. A request for variance is also referred to as a request for 
deviation, waiver, or concession. 

• CM-3.2 - Determine the security aspects of action to coordinate, evaluate, and disposition 
requests for change or requests for variance. 

• CM-3.3 - Incorporate security aspects in requests submitted for review and approval. 

• CM-3.4 - Track and manage the security aspects of approved changes to the baseline, 
requests for change, and requests for variance. 

■ Perform Product/Service Security Evaluations (QA-2): 

• QA-2.1 - Evaluate products and services for conformance to established security criteria, 
contracts, standards, and regulations. 

• QA-2.2 - Perform the security aspects of verification and validation of the outputs of the 
life cycle processes to determine conformance to specified security requirements. 

■ Treat Security Incidents and Problems (QA-5): 

• QA-5.1 - The security aspects of incidents are recorded, analyzed, and classified. 

• QA-5.2 - The security aspects of incidents are resolved or elevated to problems. 
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• QA-5.3 - The security aspects of problems are recorded, analyzed, and classified. 

• QA-5.4-Treatments for the security aspects of problems are prioritized and 
implementation is tracked. 

• QA-5.6 - Stakeholders are informed of the status of the security aspects of incidents and 
problems. 

• QA 5.7 - The security aspects of incidents and problems are tracked to closure. 

Perform the Security Aspects of Implementation (IP-2) - Continued from detailed design review. 

Manage the Results of the Security Aspects of Implementation (IP-3): 

• IP-3.1 - Record the security aspects of implementation results and any security-related 
anomalies encountered. 

• IP-3.2 - Maintain traceability of the security aspects of implemented system elements. 

• IP-3.3 - Provide security-relevant information items required for implementation to 
baselines. 

Perform the Security Aspects of Integration (IN-2) - Continued from the design phase. 

Manage the Results of the Security Aspects of Integration (IN-3): 

• IN-3.1 - Record the security aspects of integration results and any security anomalies 
encountered. 

• IN-3.2 - Maintain traceability of the security aspects of integrated system elements. 

• IN-3.3 - Provide security-relevant information items required for integration to baselines. 

Prepare for the Security Aspects of Verification (VE-1) - Continued from the design phase. 

Perform Security-Focused Verification (VE-2): 

• VE-2.1 - Define the security aspects of the verification procedures, each supporting one or 
a set of security-focused verification actions (continued from detailed design review). 


2309 A.5 Control/Testing 

2310 The primary purpose of the test milestone was to determine that the cybersecurity solution developed 

2311 and tested during the Execution phase was ready for publication. During the Control phase, formally 

2312 controlled and focused testing was performed to uncover errors and bugs in the cybersecurity solution 

2313 prior to publication that needed to be resolved. See Section 7 of this publication. 

2314 The Control/test activity was focused primarily on the following systems security engineering tasks 

2315 described in Chapter 3 of NIST SP 800-160 : 

2316 ■ Maintain the Secure Infrastructure (IF-2) - Continued from build phase. 
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■ Perform Security Quality Management Corrective and Preventive Actions (QM-3) - Continued 
from build phase. 

■ Manage Security Knowledge, Skills, and Knowledge Assets (KM-4) - Continued from build phase. 

■ Assess the Security Aspects of the Project (PA-2): 

• PA-2.9 - Analyze security measurement results and make recommendations (continued 
from build phase). 

• PA-2.10 - Record and provide security status and security findings from the assessment 
tasks. 

■ Control the Security Aspects of the Project (PA-3) - Continued from build phase. 

■ Monitor Security Risks (RM-5) - Continued from build phase. 

■ Perform the Security Aspects of Information Management (IM-2): 

• IM-2.1 - Securely obtain, develop, or transform the identified information items. 

• IM-2.2 - Securely maintain information items and their storage records and record the 
security status of information. Perform Product and Service Security Evaluations (QA-2) 
(continued from build phase). 

■ Perform Process Security Evaluations (QA-3): 

• QA-3.1 - Evaluate project life-cycle processes for conformance to established security 
criteria, contracts, standards, and regulations. 

• QA-3.2 - Evaluate tools and environments that support or automate the process for 
conformance to established security criteria, contracts, standards, and regulations. 

• QA-3.3 - Evaluate supplier processes for conformance to process security requirements. 

■ Treat Security Incidents and Problems (QA-5) - Continued from build phase. 

■ Manage Results of the Security Aspects of Implementation (IP-3) - Continued from build phase. 

■ Manage Results of the Security Aspects of Integration (IN-3) - Continued from build phase. 

■ Perform Security-Focused Verification (VE-2): 

• VE-2.2 - Perform security verification procedures. 

• VE-2.3 - Analyze security-focused verification results against any established expectations 
and success criteria. 

■ Manage Results of Security-Focused Verification (VE-3): 

• VE-3.1 - Record the security aspects of verification results and any security anomalies 
encountered. 


NIST SP 1800-14B: Protecting the Integrity of Internet Routing 


83 



2348 

2349 

2350 

2351 

2352 

2353 

2354 

2355 

2356 

2357 

2358 

2359 

2360 

2361 

2362 

2363 

2364 

2365 

2366 

2367 

2368 

2369 

2370 

2371 

2372 

2373 

2374 

2375 

2376 

2377 


DRAFT 


• VE-3.2 - Record the security characteristics of operational incidents and problems and 
track their resolution. 

A.6 Project Closing 

Project closing activities included drafting and publishing the Practice Guide. Ongoing activities may 
continue to include additional capability demonstrations. 

A.6.1 Draft Practice Guide 

During the compose Practice Guide milestone, the cybersecurity solution operated in a full-scale 
demonstration environment to show readiness for sustained use and operations, and was ready for 
draft publication as a NIST 1800-series publication. 

The draft Practice Guide activity was focused primarily on the following systems security engineering 
tasks described in Chapter 3 of NIST SP 800-160 : 

■ Share Security Knowledge and Skills Throughout the Organization (KM-2): 

• KM-2.1 - Establish and maintain a classification for capturing and sharing security 
knowledge and skills. 

• KM-2.2 - Capture or acquire security knowledge and skills. 

• KM-2.3 - Share security knowledge and skills across the organization. 

■ Manage Security Knowledge, Skills, and Knowledge Assets (KM-4) - Continued from Control/test 
phase. 

■ Define the Security Aspects of the Problem (PL-1): 

• PL-1.3 - Define and maintain a security view of the life-cycle model and its constituent 
stages. 

■ Manage the Security Aspects of the Risk Profile (RM-2): 

• RM-2.1 - Define and record the security risk thresholds and conditions under which a level 
of risk may be accepted. 

• RM-2.2 - Establish and maintain the security aspects of the risk profile. 

• RM-2.3 - Provide the security aspects of the risk profile to stakeholders based on their 
needs. 

■ Analyze Security Risks (RM-3) - Revisited process employed during the design phase. 

■ Treat Security Risk (RM-4) - Revisited process employed during the design phase. 

■ Perform the Security Aspects of Information Management (IM-2): 
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• IM-2.1 - Securely obtain, develop, or transform the identified information items (continued 
from Control/test phase). 

• IM-2.2 - Securely maintain information items and their storage records and record the 
security status of information (continued from Control/test phase). 

• IM-2.3 - Securely publish, distribute, or provide access to information and information 
items to designated stakeholders. 

• IM-2.4 - Securely archive designated information. 

• IM-2.5 - Securely dispose of unwanted or invalid information or information that has not 
been validated. 

■ Manage Quality Assurance Records and Reports (QA-4): 

• QA-4.1 - Create records and reports related to the security aspects of quality assurance 
activities. 

• QA-4.2 - Securely maintain, store, and distribute records and reports. 

• QA-4.3 - Identify the security aspects of incidents and problems associated with product, 
service, and process evaluations. 

■ Manage the Security Aspects of Business/Mission Analysis (BA-5): 

• BA-5.1 - Maintain traceability of the security aspects of business or mission analysis. 

• BA-5.2 - Provide security-relevant information items required for business or mission 
analysis to baselines. 

■ Manage the Security Aspects of System Analysis (SA-3) - Revisited process employed during the 
design phase. 

■ Manage Results of the Security Aspects of Implementation (IP-3) - Continued from build and 
Control/test phases. 

■ Manage Results of Security-Focused Verification (VE-3): 

• VE-3.3 - Obtain stakeholder agreement that the system or system element meets the 
specified system security requirements and characteristics. 

■ Prepare for the Security Aspects of Validation (VA-1): 

• VA-1.1 - Identify the security aspects of the validation scope and corresponding security- 
focused validation. 

• VA-1.2 - Identify the constraints that can potentially limit the feasibility of the security- 
focused validation actions. 

• VA-1.3 - Select the appropriate methods or techniques for the security aspects of 
validation and the associated security criteria for each security-focused validation action. 
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• VA-1.4 - Develop the security aspects of the validation strategy. 

• VA-1.5 - Identify system constraints resulting from the security aspects of validation to be 
incorporated into the stakeholder security requirements. 

• VA-1.6 - Identify, plan for, and obtain access to enabling systems or services to support the 
security aspects of validation. 

A.6.2 Special Publication Process 

During the publish SP milestone, comments on the Cybersecurity Practice Guide were resolved, and it 
was published as a NIST SP. 

The SP activity was focused primarily on the following systems security engineering tasks described in 
Chapter 3 of NIST SP 800-160 : 

■ Share Security Knowledge Assets Throughout the Organization (KM-3): 

• KM-3.3 - Securely share knowledge assets across the organization. 

■ Define the Security Aspects of the Problem (PL-1) - Continued activity from the draft Practice 
Guide phase: 

• PL-1.3 - Define and maintain a security view of the life-cycle model and its constituent 
stages. 

■ Manage the Security Aspects of the Risk Profile (RM-2) - Continued activity from the draft 
Practice Guide phase. 

■ Analyze Security Risks (RM-3) - Continued activity from the draft Practice Guide phase. 

■ Treat Security Risk (RM-4) - Continued activity from the draft Practice Guide phase. 

■ Manage Quality Assurance Records and Reports (QA-4) - Continued activity from the draft 
Practice Guide phase. 

■ Manage the Security Aspects of Business/Mission Analysis (BA-5) - Continued activity from the 
draft Practice Guide phase. 

■ Manage Results of the Security Aspects of Implementation (IP-3) - Continued activity from the 
draft Practice Guide phase. 

■ Prepare for the Security Aspects of Validation (VA-1) - Continued activity from the draft Practice 
Guide phase. 
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Appendix B Cybersecurity Education and Training 

B.l Assumptions and Limitations 

Internet service provider (ISP) personnel have many duties related to operating a service provider 
network, of which cybersecurity is only one part. Likewise, enterprise personnel have many duties 
related to operating the enterprise's own network, of which cybersecurity is only one part. This 
appendix discusses only Resource Public Key Infrastructure (RPKI)-based route origin validation 
(ROV)-specific training that is recommended for enterprise and ISP personnel. 

B.2 Staff Role Perspective 

The perspective from which a staff member will need to be familiar with software, equipment, and 
procedures and to consult pertinent standards will differ depending on that staff member's role within 
the organization (regardless of whether the organization is an ISP or an enterprise): 

■ The procurement staff will need to understand ROV and RPKI standards to the extent that they 
are able to ensure that the standards are supported by the equipment being purchased. 

■ Managers will need to understand these standards to the extent that they are able to ensure 
that their organization has all software, equipment, personnel, and procedures in place to 
perform their RPKI-based ROV role(s) correctly and in a manner that is consistent with business 
policies and objectives. 

■ Operations and maintenance personnel will need to understand these standards to the extent 
that these personnel will enable the staff to support day-to-day RPKI-based ROV operations. 

B.3 ISP Versus Enterprise Training Requirements 

There is not necessarily a strict distinction between the type of RPKI-based ROV training that is needed 
at enterprises versus that which is needed at ISPs. Rather, the type of training that is required depends 
more on the roles that each organization assumes with respect to RPKI-based ROV. 

All ISPs have dual RPKI-based ROV roles, in the sense that they serve as both network operators and 
address holders. In their capacity as network operators, they are concerned with obtaining and using 
RPKI information to perform ROV; in their capacity as address holders, they are concerned with creating 
route origin authorizations (ROAs) to help protect their addresses from being hijacked. Hence, the ISP 
staff need training in both the ROV-related and RPKI-related areas. 

Unlike ISPs, enterprises do not necessarily need to perform ROV. Instead, an enterprise may rely on its 
service provider to perform ROV on its behalf. If an enterprise does not perform ROV, then its staff does 
not need training in ROV-related areas; however, if the enterprise does perform ROV, then its staff will 
need the same ROV training as the ISP staff. 
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2471 Assuming that an enterprise is an address holder, it will need training in RPKI-related areas. One 

2472 important difference between the RPKI training needed at ISPs versus enterprises stems from the fact 

2473 that an ISP has a choice of deploying either the hosted or delegated model of RPKI, whereas an 

2474 enterprise will always use the hosted model. 

2475 B.4 ROV Training Requirements 

2476 Organizations (whether they be ISPs or enterprises) that will perform ROV will need training in, and 

2477 familiarity with: 

2478 ■ BGP routers 

2479 ■ RPKI validating caches 

2480 B.5 ISP RPKI Training Requirements 

2481 ISPs will need training in, and familiarity with: 

2482 ■ general RPKI information 

2483 ■ depending on which model the ISP chooses to use, either of the following two models: 

2484 • RPKI hosted model 

2485 • RPKI delegated model 

2486 Managers at the ISP who are responsible for choosing which model to use will need to be familiar with 

2487 both the hosted and delegated models. 

2488 B.6 Enterprise RPKI Training Requirements 

2489 Enterprises that are address holders and want to create ROAs to protect those addresses will need 

2490 training in, and familiarity with: 

2491 ■ general RPKI information 

2492 ■ RPKI hosted model 

2493 B.7 List of Standards and other Training Materials 

2494 The standards and other material with which the staff should be familiar under each topic area that is 

2495 relevant to ROV and RPKI are as follows: 

2496 BGP Router Information; 

2497 ■ RFC 6810, The RPKI to Router Protocol (vO) 

2498 ■ RFC 8210, The RPKI to Router Protocol (vl) 
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■ RFC 6811, BGP Prefix Origin Validation 

■ RFC 8097, BGP Prefix Origin Validation State Extended Community 

■ Information regarding the configuration and use of the ROV-specific components of the border 
routers being used, including configuring routing policy based on the validation state 

RPKI Validating Cache Information; 

■ RFC 5781, The Remote Synchronization (rsync) URI Scheme 

■ RFC 8182. The RRDP 

■ RFC 6487, A Profile for X.509 PKIX Resource Certificates 

■ RFC 6488, Signed Object Template for the RPKI 

■ Information regarding the installation and use of the specific validating cache software being 
used 

■ RFC 6486, Manifests for the RPKI 

General RPKI Information: 

■ RFC 6481, A Profile for Resource Certificate Repository Structure 

■ RFC 7730, RPKI Trust Anchor Locator 

RPKI Hosted-Model Information: 

The ISP staff should be familiar with the Regional Internet Registry (RIR) (or other authority) web 
interface that they will need to use to request that ROAs for their addresses be created and stored. The 
ISP staff should receive training in both the mechanics of how to use the web interface and the meaning 
and ramifications of selecting various available options. (This information is only of interest to 
enterprises and also to ISPs that plan to use the hosted model of RPKI for generating and storing ROAs 
for their addresses.) 

RPKI Delegated-Model Information: 

It is assumed that staff at these ISPs are already familiar with all standards related to running an X.509 
certificate authority (CA), in general, independent of ROV. In addition, in order to be able to support the 
extensions to X.509 that are required for a delegated-model CA to support ROV, the ISP staff should be 
familiar with: 

■ RFC 3779, X.509 Extensions for IP Addresses and AS Identifiers 

■ RFC 6480, An Infrastructure to Support Secure Internet Routing 

■ RFC 6481, A Profile for Resource Certification Repository Structure 

■ RFC 6482. A Profile for ROAs 
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2530 ■ RFC 7115, Origin Validation Operation Based on the RPKI (operational considerations) 

2531 ■ RFC 6492, A Protocol for Provisioning Resource Certificates 

2532 (This information is only of interest to ISPs that plan to set up their own CA and repository publication 

2533 point.) 
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Appendix C Secure Inter-Domain Routing Project Mapping 
to the Cybersecurity Framework Core and 
Informative References 

This appendix provides more detailed information regarding the security controls mapping of the 
Cybersecurity Framework categories and sub-categories to the functionality supported by components 
of the secure inter-domain routing (SIDR) reference architecture solution, as well as a discussion of 
additional references, standards, and guidelines that informed the SIDR Project. 

C.l Cybersecurity Framework Functions, Categories, and Subcategories 
Addressed by the Secure Inter-Domain Routing Project 

The following Cybersecurity Framework categories and subcategories are supported by the SIDR 
Project: 


■ The Protect function involves developing and implementing the appropriate safeguards needed 
to ensure delivery of critical infrastructure services. The following SIDR platform capabilities 
support the Protect function: 

• The Integrity and Authenticity of Routing information (ensuring that Border Gateway 
Protocol [BGP] routes are originated from an authorized autonomous system [AS]) 
supports the Data Security (PR.DS) category under the Protect function. The Data 
Security (PR.DS) category includes managing information and data that are consistent with 
the organization's risk strategy to protect the confidentiality, integrity, and availability of 
information. The following subcategories are supported by the platform: 

o PR.DS-1 - Data-at-rest is protected. 

o PR.DS-2 - Data-in-transit is protected. 

o PR.DS-6 - Integrity checking mechanisms are used to verify information integrity. 

• System and Application Flardening (adjusting security controls on the server and/or 
software applications such that security is maximized ["hardened"] while maintaining the 
intended use) supports the Information Protection Processes and 

Procedures (PR.IP) category under the Protect function. The Information Protection 
Processes and Procedures category involves maintaining and using security policies, 
processes, and procedures to manage the protection of information systems and assets. 

• Device Protection (ensuring the protection of devices, communications, and control 
networks) supports the Access Control and Protective Technology categories under 
the Protect function: 

o Access Control (PR.AC) includes the limiting of access to logical assets to authorized 
users and processes. The following subcategories are supported by the platform: 
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2576 

2577 

2578 

2579 

2580 

2581 

2582 

2583 

2584 

2585 

2586 

2587 

2588 

2589 

2590 

2591 

2592 

2593 

2594 

2595 

2596 

2597 

2598 

2599 

2600 
2601 


PR.AC-3 - Remote access is managed. 

PR.AC-5 - Network integrity is protected, incorporating network segregation where 
appropriate. 

o Protective Technology (PR.PT) includes managing technical security solutions to ensure 
that the security and resilience of systems and assets are consistent with related 
policies, procedures, and agreements. A subcategory supported by the platform is as 
follows: 

PR.PT-4 - Communications and control networks are protected. 

■ The Detect function involves developing and implementing the appropriate activities to identify 
the occurrence of a cybersecurity event. Protecting the authenticity of routing information and 
detecting anomalous routes support the following categories under the Detect function: 

Security Continuous Monitoring (DE.CM) includes monitoring information systems and 
assets to identify cybersecurity events. The following subcategories are supported by the 
platform: 

o DE.CM-4 - Malicious code is detected. 

o DE.CM-7 - Monitoring for unauthorized personnel, connections, devices, and software 
is performed. 

• Detection Processes (DE.DP) include maintaining and testing detection processes and 
procedures to ensure timely and adequate awareness of anomalous events. The following 
subcategories are supported by the platform: 

o DE.DP-3 - Detection processes are tested. 

o DE.DP-4 - Event detection information is communicated to appropriate parties. 

■ The Respond function involves supporting the development and implementation of the 
appropriate activities that take action regarding a detected cybersecurity event. Platform 
capabilities that support the Respond function include ensuring the integrity of network 
connections in the case of incidents that result in a compromise. The effects of the compromise 
can be limited by the exclusion of systems and devices that have not implemented the integrity 
mechanisms. Also, when routes that originated from unauthorized ASes are received, these can 
be logged and reported. The platform supports the Communications and Mitigation categories 
under the Response function: 

• Communications (RS.CO) includes the coordination of response activities with internal and 
external stakeholders. The following subcategories are supported by the platform: 

o RS.CO-2 - Events are reported consistent with response plans. 

o RS.CO-3—Information is shared consistent with response plans. 
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• Mitigation (RS.MI) includes preventing the expansion of events, mitigating their effects, 
and eradicating incidents. A subcategory supported by the platform is as follows: 

o RS.MI-1 - Incidents are contained. 

C.2 Cybersecurity References Directly Tied to Those Cybersecurity 
Framework Categories and Subcategories Addressed by the Secure 
Inter-Domain Routing Project 

The following references are mapped to the Cybersecurity Framework subcategories identified in 
Table 4-1 in Section 4.4.4 as being addressed by the SIDR security platform: 

■ information Technology - Security technigues - Information security management systems - 
Reguirements ( ISO/IEC 27001:2013 ) Sections A.6.1.3, A.6.1.5, A.6.2.2, A.8.2.3, A.12.1.2, A.12.2.1, 
A.12.5.1, A.12.6.2, A. 13.1.1, A. 13.1.3, A. 13.2.1, A. 13.2.3, A.14.1.1, A.14.1.2, A.14.1.3, A.14.2.1, 
A.14.2.2, A.14.2.3, A.14.2.4, A.14.2.5, A.14.2.8, A.16.1.2, and A.16.1.5. 

■ Security and Privacy Controls for Federal Information Systems and Organizations ( SP 800-53) 
controls AC-4, AC-17, AC-18, AC-19, AC-20, AU-6, AU-12, CA-2, CA-7, CM-2, CM-3, CM-4, CM-5, 
CM-6, CM-7, CM-8, CM-9, CP-2, CP-8, IR-4, IR-6, IR-8, PE-3, PE-6, PE20, PL-8, PM-14, RA-5, SA-3, 
SA-4, SA-8, SAIO, SA-11, SA-12, SA-15, SA-17, SC-7, SC-28, SI-3, and SI-4. 

C.3 Other Security References Applied in the Design and Development of 
the Secure Inter-Domain Routing Project 

The references, standards, and guidelines that informed the SIDR Project include federal policies and 
standards, NIST guidelines and recommendations, and Internet Engineering Task Force (IETF) standards 
(published as Requests for Comments [RFCs]). Relevant documents include 0MB Circular A-130: FIPS 
140-2: NIST SP 800-37 Rev. 1: NIST SP 800-53 Rev. 4: NIST SP 800-54: NISTSP 800-57 Part 1: NISTSP 800- 
130: NIST SP 800-152: NIST SP 800-160: NIST Framework for Improving Critical Infrastructure 
Cvbersecuritv. and RFCs 3882, 4012, 4593, 5280, 5575, 6092, 6472, 6480, 6481, 6495, 6810, 6811, 6907, 
7115, 7318, 7454, 7674, 7908, 7909, 8097, 8182, and 8205 . The project was also informed by the in¬ 
progress draft of NIST SP 800-189 {Secure Interdomain Traffic Exchange) and several internet drafts on 
BGP security and robustness (see Appendix D ). 
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Appendix D Assumptions Underlying the Build 

This project was guided by the following assumptions. 

D.l Security and Performance 

An underlying assumption was that the benefits of using the Resource Public Key Infrastructure (RPKI) 
and route origin validation (ROV) tools and protocols demonstrated in this project outweighed any 
additional performance risks that may be introduced by instantiating the security protocols. The 
assessment of the security of current systems and networks is out of scope for this project. A key 
assumption is that most potential adopters of the demonstrated builds, or any build components, do 
not already have RPKI-based ROV protocols in place. We focused on what potential security impacts 
were being introduced to end users if they implement this solution. The goal of this solution was to 
provide RPKI-based ROV services without introducing additional performance or reliability risks into 
existing systems, but there is always an inherent risk of increased overhead and interoperability issues 
when adding systems and adding new features into an existing system. 

D.2 Modularity 

The modular approach taken in this project was based on one of the National Cybersecurity Center of 
Excellence (NCCoE) core operating tenets. It was assumed that organizations already have routing 
systems in place. Our philosophy is that a combination of certain components or a single component can 
improve routing security for an organization; the organization may not need to remove or replace most 
of its existing infrastructure. For example, some commercial routers already come with ROV/ RFC 6811 
implemented. It is only a matter of turning it on. This guide provides a complete top-to-bottom solution 
and is also intended to provide various options based on need. 

D.3 Technical Implementation 

This Practice Guide is written from a "how to" perspective, and its foremost purpose is to provide details 
on how to install, configure, and integrate the components. The NCCoE assumes that an organization 
has the technical resources to implement all or parts of the build or has access to companies that can 
perform the implementation on its behalf. 

D.4 Operating System and Virtual Machine Environments 

This project used commercially available routers and open-source software integrated into a VMware 
vCenter server Version 6.0.0 Build 3018523 virtual machine (VM) environment. It is assumed that user 
organizations will be able to use physical or virtual routers and that they will be able to install the 
demonstrated applications on cloud-hosted VMs, local VMs, or local native server client environments. 
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D.5 Address Holder Environments 

It is assumed that address holders understand the usage of RPKI resources and have agreements in 
place with a Regional Internet Registry (RIR) or other authority that enable route origin authorizations 
(ROAs) for addresses that they hold to be created and signed. The address holder has two options for 
creating the ROAs: the hosted or the delegated model. 

D.5.1 Hosted 

In the hosted model, the address holder assumes the responsibility of having the internet protocol (IP) 
addresses that it holds registered with the proper RIR to create end-entity (EE) certificates and ROAs. 

The RPKI infrastructure that is used to create the certificate authority (CA) certificates and store ROAs is 
managed by the RIR. Address holders should have ROAs only in the RPKI repository corresponding to the 
RIR or other authority that allocated or administers the address prefixes that are in the ROAs. 

D.5.2 Delegated 

Unlike the hosted environment, in the delegated environment, the RPKI infrastructure that is used to 
create the CA certificates and ROAs is managed by the address holder's organization. It is assumed that 
the address holder or their organization has the resources to design, configure, and operate the 
components of the RPKI infrastructure. The actual design and implementation of the RPKI infrastructure 
can be the responsibility of the address holder or assigned to the network operators or other 
information technology (IT) groups within the organization. In this model, a transit internet service 
provider (ISP) in the allocation hierarchy may offer the RPKI service of maintaining certificates, private 
keys, and ROAs to its customers. 

D.6 Network Operator Environments 

Network operators provide Border Gateway Protocol (BGP)-based routing services to route traffic to and 
from endpoints within their network and customer/peer networks in other autonomous systems (ASes). 
(Note that network operators may also be address holders, but whether they are or not does not impact 
their role as network operators.) For this document, the network operator is responsible for operating 
and managing the network environment, including monitoring and managing tools used for ROV, such as 
RPKI validating caches and RPKI-aware BGP routers. From an operational standpoint, when RPKI, ROAs, 
and ROV are being used, the network operator's role does not change depending on whether a hosted 
or delegated RPKI model is being used. In both cases, network operators are responsible for using ROA 
information to perform BGP ROV on routes that they receive. 

D.7 Regional Internet Registry Environments 

RIRs play vital roles in RPKI, both in terms of assisting with the creation of RPKI content by address 
holders and in terms of making that content available to relying parties. Regarding RPKI content creation 
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for the hosted RPKI model, the RIRs provide an online hosting service to enable their customers to 
generate EE certificates and ROAs. For example, the Reseaux IP Europeens Network Coordination Centre 
(RIPE NCC) provides a web-based portal for its customers to securely log into and manage their ROAs. 

For organizations that choose to use the delegated model and run their own CA, there is open-source 
software available to create the RPKI infrastructure and securely communicate with the RIR parent 
system. 

RIRs also make the content of their RPKI repositories available to relying parties so that relying parties 
can use this information to perform ROV on the route advertisements that they receive. When a hosted 
model of RPKI has been used to cause the RIR to assist in the creation of an ROA, the RIR stores that ROA 
in its repository and makes the ROA directly available to all relying parties. When a delegated model of 
RPKI has been used to create an ROA, the RIR stores the Universal Resource Indicator (URI )that relying 
parties need to use in its repository in order to locate the publication point for the ROA. 

D.8 Route Acceptance Decisions for Invalid and Not Found Routes 

With the use of RPKI, BGP ROV results in BGP routes that are evaluated as either valid, invalid, or not 
found. While accepting the valid routes for usage is the default recommendation and non-controversial, 
organizations should use their local route selection policies for routes that are invalid or not found. 

D.8.1 Decision Made by Service Provider 

Service providers may have policies that are different due to their own local policies or the need to pass 
on routes to their customers. It is outside the scope of this project to consider incremental or partial 
deployment models as may be encountered by large commercial ISPs. 

D.8.2 Decision Made by Enterprise 

Enterprises that receive a default route from their service provider will not need to perform ROV 
because there is no need to use BGP ROV in this case. All traffic from the enterprise will always travel on 
the same single (default) route from the enterprise to its ISP. All traffic to the enterprise will travel on a 
static route from the ISP to the enterprise's public IP address range. On the other hand, enterprises that 
receive BGP routes from their peers will need to have a policy regarding how to address routes that are 
invalid or not found. 
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Appendix E Functional Test Requirements and Results 

E.l Functional Test Plans 

This test plan presents the functional requirements and associated test cases necessary to conduct the 
functional evaluation of the secure inter-domain routing (SIDR) example implementation. The SIDR 
example implementation is currently deployed in a lab at the National Cybersecurity Center of 
Excellence (NCCoE). The implementation tested is described in Section 7 . The test cases are performed 
using the following architectures. Figure E-1 depicts the testbed using the test harness (Border Gateway 
Protocol [BGP] traffic generation and collection framework - BGPSEC-IO [BIO]). Figure E-2 depicts the 
testbed using live traffic. 


Figure E-1 SIDR Testbed Using the Test Harness 



BGPSEC-IO (BIO) - BGP traffic generator & collector / RTR- CISCO or Juniper Router 
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2731 Figure E-2 SIDR Testbed Using Live Traffic 


2732 
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2733 E.2 Requirements 

2734 Table E-1 identifies the SIDR functional evaluation requirements that are addressed in this test plan, and 

2735 their associated test cases. 

2736 Table E-1 SIDR Functional Requirements 


Capability 
Requirement 
(CR) ID 

Parent Requirement 

Sub-Requirement 1 

Sub-Requirement 2 

Test 

Case 

CR 1 

The SIDR example 
implementation shall 
include a capability for BGP 
routers to perform route 
origin validation (ROV) on 
all routes that they receive 
in BGP update messages. 

The router will be capable 
of accurately establishing an 
initial validation state (valid, 
invalid, or not found) for a 
given route and marking the 
route accordingly. The 
router will also be capable 
of accurately re-evaluating 
that route's validation state 
after Resource Public Key 
Infrastructure (RPKI) test 
data has been perturbed, 
re-marking the route (if 
applicable). 




CR 1.1 


The advertised 
route is initially 
evaluated as valid. 
The single route 
origin authorization 
(ROA) that had 
made the route 

valid is removed 
from the RPKI; 
there is no ROA 

that covers the 
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Capability 
Requirement 
(CR) ID 

Parent Requirement 

Sub-Requirement 1 

Sub-Requirement 2 

Test 

Case 



route, so the route 
is re-evaluated as 
not found. 



CR 1.1.1 



IPv4 address type 

SIDR- 

ROV- 

1.1.1 

CR-1.1.2 



IPv6 address type 

SIDR- 

ROV- 

1.1.2 

CR-1.2 


The advertised 
route is initially 
evaluated as valid. 
The single ROA that 
had made the 

route valid is 

removed from the 

RPKI. There is 

another ROA that 
covers the route, 
but the 

autonomous 
system number 
(ASN) in this ROA 
does not match 

that of the route's 
origin, so the route 
is re-evaluated as 

invalid. 



CR-1.2.1 



IPv4 address type 

SIDR- 

ROV- 

1.2.1 

CR-1.2.2 



IPv6 address type 

SIDR- 

ROV- 

1.2.2 

CR-1.3 


The advertised 
route is initially 
evaluated as valid. 
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Capability 
Requirement 
(CR) ID 

Parent Requirement 

Sub-Requirement 1 

Sub-Requirement 2 

Test 

Case 



The single ROA that 
had made the 

route valid is 

removed from the 

RPKI. There is 

another ROA that 
covers the route, 
but its maximum 
prefix length is less 
than the prefix 
length of the route, 
so the route is re¬ 
evaluated as 

invalid. 



CR-1.3.1 



IPv4 address type 

SIDR- 

ROV- 

1.3.1 

CR-1.3.2 



IPv6 address type 

SIDR- 

ROV- 

1.3.2 

CR1.4 


The advertised 
route is initially 
evaluated as vaiid. 

An ROA that had 

made the route 

valid is removed 
from the RPKI; 
there remains 

another ROA that 
matches the route, 
so the route still 

evaluates as vaiid. 



CR-1.4.1 



IPv4 address type 

SIDR- 

ROV- 

1.4.1 
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Capability 
Requirement 
(CR) ID 

Parent Requirement 

Sub-Requirement 1 

Sub-Requirement 2 

Test 

Case 

CR-1.4.2 



IPv6 address type 

SIDR- 

ROV- 

1.4.2 

CR-1.5 


The advertised 
route is initially 
evaluated as not 
found. An ROA that 
matches the route 

is added to the 

RPKI, so the route 
is re-evaluated as 

valid. 



CR-1.5.1 



IPv4 address type 

SIDR- 

ROV- 

1.5.1 

CR-1.5.2 



IPv6 address type 

SIDR- 

ROV- 

1.5.2 

CR-1.6 


The advertised 
route is initially 
evaluated as not 
found. An ROA that 
covers this route, 
but that has an ASN 

different from that 

of the route's 
origin, is added to 
the RPKI, so the 
route is re¬ 
evaluated as 

invalid. 



CR-1.6.1 



IPv4 address type 

SIDR- 

ROV- 

1.6.1 

CR-1.6.2 



IPv6 address type 

SIDR- 

ROV- 

1.6.2 
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Capability 
Requirement 
(CR) ID 

Parent Requirement 

Sub-Requirement 1 

Sub-Requirement 2 

Test 

Case 

CR-1.7 


The advertised 
route is initially 
evaluated as invalid 

due to an ROAthat 
covers this route, 
but that has an ASN 

different from that 

of the route's 
origin. A second 

ROA that matches 

this route is added 
to the RPKI, so the 
route is re¬ 
evaluated as valid. 



CR-1.7.1 



IPv4 address type 

SIDR- 

ROV- 

1.7.1 

CR-1.7.2 



IPv6 address type 

SIDR- 

ROV- 

1.7.2 

CR 1.8 


The advertised 
route is initially 
evaluated as invalid 

due to the 
presence of one 

ROA that covers 
this route, but that 
has an ASN 

different from that 

of the route's 
origin. This is the 
only ROAthat 
covers the route. It 

is deleted from the 
RPKI, so the route 
is re-evaluated as 
not found. 
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Capability 
Requirement 
(CR) ID 

Parent Requirement 

Sub-Requirement 1 

Sub-Requirement 2 

Test 

Case 

CR-1.8.1 



IPv4 address type 

SIDR- 

ROV- 

1.8.1 

CR-1.8.2 



IPv6 address type 

SIDR- 

ROV- 

1.8.2 

CR-1.9 


The advertised 
route is initially 
evaluated as 

invalid. There are 

two ROAs that 
cover this route, 
both of which have 

ASNs different from 
the route's origin. 
Only one of these 
ROAs is deleted 
from the RPKI, so 
the route still 

evaluates as 

invalid. 



CR-1.9.1 



IPv4 address type 

SIDR- 

ROV- 

1.9.1 

CR-1.9.2 



IPv6 address type 

SIDR- 

ROV- 

1.9.2 

CR-1.10 


The advertised 
route is initially 
evaluated to be 

invaiid due to the 

fact that it contains 
AS_SET, even 
though there is an 
ROA that covers 

the route and that 

has a maximum 
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Capability 
Requirement 
(CR) ID 

Parent Requirement 

Sub-Requirement 1 

Sub-Requirement 2 

Test 

Case 



length greater than 
the route's prefix. A 
second 

advertisement is 

received for this 

same route that 

does not contain 
AS_SET and that is 
matched by the 

ROA that is already 
in the RPKI. The 

route in this second 

advertisement is 

evaluated as valid. 



CR-1.10.1 



IPv4 address type 

SIDR- 

ROV- 

1.10.1 

CR-1.10.2 



IPv6 address type 

SIDR- 

ROV- 

1.10.2 

CR-2 

The SIDR example 
implementation shall 
include a capability for BGP 
routers to perform ROV on 
all routes that are 

redistributed into BGP from 
another source, such as 
another protocol or a locally 
defined static route. The 
router will be capable of 
accurately establishing an 
initial validation state (valid, 
invalid, or not found) for a 
given route, marking the 
route accordingly, and 
applying appropriate policy 
depending on the result. 

The router will also be 
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Capability 
Requirement 
(CR) ID 

Parent Requirement 

Sub-Requirement 1 

Sub-Requirement 2 

Test 

Case 


capable of accurately re¬ 
evaluating that route's 
validation state after RPKI 

test data has been 
perturbed, re-marking the 
route (if applicable), and 
applying appropriate policy 
depending on the (possibly) 
new result. 




CR-2.1 


A route is 

redistributed into 

BGP from a locally 
defined static 

route. This route is 
initially evaluated 
as valid. The single 
ROA that had made 

the route valid is 

removed from the 

RPKI. There is 

another ROA that 
covers the route, 
but the ASN in this 

ROA does not 

match that of the 
route's origin, so 
the route is re¬ 
evaluated as 

invalid. 



CR-2.1.1 



IPv4 address type 

SIDR- 

ROV- 

2.1.1 

CR-2.1.2 



IPv6 address type 

SIDR- 

ROV- 

2.1.2 
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Capability 
Requirement 
(CR) ID 

Parent Requirement 

Sub-Requirement 1 

Sub-Requirement 2 

Test 

Case 

CR-2.1.3 



IPv4 address type 
and virtual router 
instead of physical 
router 

SIDR- 

ROV- 

2.1.3 

CR-2.2 


A route is 

redistributed into 

BGP from a locally 
defined static 

route. The route is 
initially evaluated 
as not found. An 

ROA that matches 

the route is added 
to the RPKI, so the 
route is re¬ 
evaluated as valid. 



CR-2.2.1 



IPv4 address type 

SIDR- 

ROV- 

2.2.1 

CR-2.2.2 



IPv6 address type 

SIDR- 

ROV- 

2.2.2 

CR-2.3 


A route is 

redistributed into 

BGP from a locally 
defined static 

route. The 

advertised route is 
initially evaluated 
as not found. An 

ROA that covers 
this route, but that 
has an ASN 

different from that 

of the route's 
origin, is added to 
the RPKI, so the 
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Capability 
Requirement 
(CR) ID 

Parent Requirement 

Sub-Requirement 1 

Sub-Requirement 2 

Test 

Case 



route is re¬ 
evaluated as 

invalid. 



CR-2.3.1 



IPv4 address type 

SIDR- 

ROV- 

2.3.1 

CR-2.3.2 



IPv6 address type 

SIDR- 

ROV- 

2.3.2 

CR-3.1 


A route is 

redistributed into 

BGP from an 
interior gateway 
protocol (IGP). This 
route is initially 
evaluated as valid. 
The single ROA that 
had made the 

route valid is 

removed from the 
RPKI; there is no 

ROA that covers 
the route, so the 
route is re¬ 
evaluated as not 
found. 



CR-3.1.1 



IPv4 address type 

SIDR- 

ROV- 

3.1.1 

CR-3.2 


A route is 

redistributed into 

BGP from an IGP. 

This route is 
initially evaluated 
as invalid due to an 

ROA that covers 
this route, but that 
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Capability 
Requirement 
(CR) ID 

Parent Requirement 

Sub-Requirement 1 

Sub-Requirement 2 

Test 

Case 



has an ASN 

different from that 

of the route's 
origin. A second 

ROA that matches 

this route is added 
to the RPKI, so the 
route is re¬ 
evaluated as valid. 



CR-3.2.1 



IPv4 address type 

SIDR- 

ROV- 

3.2.1 

CR-3.3 


A route is 

redistributed into 

BGP from an IGP. 

This route is 
initially evaluated 
as invalid due to 
the presence of 
one ROA that 
covers this route, 
but that has an ASN 

different from that 

of the route's 
origin. This is the 
only ROA that 
covers the route. It 

is deleted from the 
RPKI, so the route 
is re-evaluated as 
not found. 



CR-3.3.1 



IPv4 address type 

SIDR- 

ROV- 

3.3.1 

CR-4 

The SIDR example 
implementation shall 
include a capability for BGP 
routers to be configured 
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Capability 
Requirement 
(CR) ID 

Parent Requirement 

Sub-Requirement 1 

Sub-Requirement 2 

Test 

Case 


with a policy that treats 
locally defined interior 
border gateway protocol 
(iBGP) routes differently 
from other iBGP routes. In 
particular, it will be possible 
to configure router policy 
such that invalid locally 
generated iBGP routes and 
invalid locally defined static 
routes are not dropped, but 
other invalid iBGP routes 

are. 




CR-4.1 


The router under 
test (RUT) 
implements its 
configured policy, 
which is to retain 

invalid routes if 
they are locally 
generated iBGP 
routes or locally 
defined static 
routes, but to drop 
all other invalid 

iBGP routes. 



CR-4.1.1 



IPv4 address type 

SIDR- 

ROV- 

4.1.1 



IPv6 address type 

SIDR- 

ROV- 

4.1.1 

CR-4.2 


ROV-capable 
routers can 

evaluate routes 
correctly within an 
iBGP network by 
using a single, but 
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Capability 
Requirement 
(CR) ID 


Parent Requirement 


Sub-Requirement 1 Sub-Requirement 2 


Test 

Case 




shared, VC for the 
iBGP peers, 
whether the routes 

are received via 

exterior border 
gateway protocol 
(eBGP), IGP, static, 
or from local 

network. 



CR-4.2.1 



IPv4 address type 

SIDR- 




with Router A 

ROV- 





4.2.1 




IPv6 address type 

SIDR- 




with Router A 

ROV- 





4.2.1 

CR-4.2.2 



IPv4 address type 

SIDR- 




with Router B 

ROV- 





4.2.2 




IPv6 address type 

SIDR- 




with Router B 

ROV- 





4.2.2 

CR-4.3 


ROV-capable 
routers can 

evaluate routes 
correctly using 
eBGP, IGP, static, 
and local network 

routes within an 
iBGP network using 
one shared VC 
within iBGP peers 
without Extended 
Community Strings. 



CR-4.3.1 



IPv4 address type 

SIDR- 




with Router A 

ROV- 





4.3.1 


NIST SP 1800-14B: Protecting the Integrity of Internet Routing 


111 

















DRAFT 


Capability 

Requirement Parent Requirement Sub-Requirement 1 Sub-Requirement 2 





IPv6 address type 

SIDR- 




with Router A 

ROV- 





4.3.1 

CR-4.3.2 



IPv4 address type 

SIDR- 




with Router B 

ROV- 





4.3.2 




IPv6 address type 

SIDR- 




with Router B 

ROV- 





4.3.2 

CR-4.4 


ROV-capable 
routers can 

evaluate routes 
correctly using 
eBGP, IGP, static, 
and local network 

routes within an 

IBGP network using 
one shared VC 
within iBGP peers 
with Extended 
Community Strings. 



CR-4.4.1 



IPv4 address type 

SIDR- 




with Router A 

ROV- 





4.4.1 




IPv6 address type 

SIDR- 




with Router A 

ROV- 





4.4.1 

CR-4.4.2 



IPv4 address type 

SIDR- 




with Router B 

ROV- 





4.4.2 




IPv6 address type 

SIDR- 




with Router B 

ROV- 





4.4.2 

CR-4.5 


ROV-capable 
routers can 

evaluate routes 




NIST SP 1800-14B: Protecting the Integrity of Internet Routing 


112 



















DRAFT 


Capability 
Requirement 
(CR) ID 


Parent Requirement 


Sub-Requirement 1 Sub-Requirement 2 


Test 

Case 




correctly using 
eBGP, IGP, static, 
and local network 

routes within an 

IBGP network using 
two distinct VCs for 
the iBGP peers 
while enabling 
Extended 

Community Strings. 



CR-4.5.1 



IPv4 address type 

SIDR- 




with Router A 

ROV- 





4.5.1 




IPv6 address type 

SIDR- 




with Router A 

ROV- 





4.5.1 

CR-4.6 


ROV-capable 
routers can 

evaluate routes 
correctly using 
eBGP, IGP, static, 
and local network 

routes within an 

IBGP network using 
two distinct VCs 
with conflicting 
records for the 
iBGP peers while 
enabling Extended 
Community String. 



CR-4.6.1 



IPv4 address type 

SIDR- 




with Router A 

ROV- 





4.6.1 




IPv6 address type 

SIDR- 




with Router A 

ROV- 





4.6.1 
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Capability 
Requirement 
(CR) ID 

Parent Requirement 

Sub-Requirement 1 

Sub-Requirement 2 

Test 

Case 

CR5 

The SIDR example 
implementation shall be 
capable of applying policies 
to the ROV-route selection 

process. 




CR5.1 


The router can be 
configured such 
that invalid routes 

are discarded and 
not found routes 
are installed with a 

low local 
preference (LP) 
value. 



CR 5.1.1 



IPv4 address type 

SIDR- 

ROV- 

5.1.1 



IPv6 address type 

SIDR- 

ROV- 

5.1.1 

CR 5.1.1 


The router can be 
configured such 
that invalid routes 

are installed with 

the lowest LP 
value, valid routes 
are installed with 
the highest LP 
value, and not 
found routes are 
installed with an LP 

value in between. 



CR 5.1.2 



IPv4 address type 

SIDR- 

ROV- 

5.1.2 
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Capability 
Requirement 
(CR) ID 

Parent Requirement 

Sub-Requirement 1 

Sub-Requirement 2 

Test 

Case 




IPv6 address type 

SIDR- 

ROV- 

5.1.2 

CR6 

The SIDR example 
implementation shall be 
capable of having the router 
and VC synchronize 
properly such that the 
correct RPKI information is 

received at the router 
following a disruption to the 
connectivity between a 
router and its VC. 




CR 6.1 


Router and cache 
get re-synchronized 
properly after loss 
of connectivity. 



CR 6.1.1 



IPv4 address type 

SIDR- 

ROV- 

6.1.1 



IPv6 address type 

SIDR- 

ROV- 

6.1.1 

CR 6.2 


Router and cache 
get re-synchronized 
properly after the 
cache loses power. 



CR 6.2.1 



IPv4 address type 

SIDR- 

ROV- 

6.2.1 



IPv6 address type 

SIDR- 

ROV- 

6.2.1 

CR 6.3 


Router and cache 
get re-synchronized 
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Capability 
Requirement 
(CR) ID 

Parent Requirement 

Sub-Requirement 1 

Sub-Requirement 2 

Test 

Case 



properly after the 
router loses power. 



CR 6.3.1 



IPv4 address type 

SIDR- 

ROV- 

6.3.1 



IPv6 address type 

SIDR- 

ROV- 

6.3.1 

CR 6.4 


Router 

synchronizes to a 
different cache 
after disconnecting 
from a previous 
cache. 



CR 6.4.1 



IPv4 address type 

SIDR- 

ROV- 

6.4.1 



IPv6 address type 

SIDR- 

ROV- 

6.4.1 

CR 6.5 


Router is 

connected to two 

caches with 

identical RPKI 
information, and 
then one of those 

caches is shut 

down. 



CR 6.5.1 



IPv4 address type 

SIDR- 

ROV- 

6.5.1 



IPv6 address type 

SIDR- 

ROV- 

6.5.1 

CR 6.6 


Router is 

connected to two 
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Capability 
Requirement 
(CR) ID 

Parent Requirement 

Sub-Requirement 1 

Sub-Requirement 2 

Test 

Case 



caches that have 

different RPKI 
information, and 
then one of those 

caches is shut 

down. 



CR 6.6.1 



IPv4 address type 

SIDR- 

ROV- 

6.6.1 



IPv6 address type 

SIDR- 

ROV- 

6.6.1 

CR-7 

The SIDR example 
implementation shall 
include the capability for a 
resource holder to set up its 
own delegated certificate 
authority (CA), create its 
own repository, and offer a 
hosted service to its 
customers, including the 
ability to publish customer 
ROAs to its repository, 
delete customer ROAs from 
its repository, and have 
customer ROAs expire from 
its repository. The ROAs in 
this delegated CA repository 
will be included in the RPKI 
data that relying parties 
download to their VCs, and 
validated ROA payloads 
(VRPs) derived from these 
ROAs will be provided to 
relying-party routers via the 
RPKI-to-router protocol. 




CR-7.1 


A resource holder is 
able to set up its 
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Capability 
Requirement 
(CR) ID 

Parent Requirement 

Sub-Requirement 1 

Sub-Requirement 2 

Test 

Case 



own delegated CA, 
create its own 
repository, create 
ROAs for the 

addresses that it 
holds, and store 
these ROAs in its 
own repository. 



CR-7.1.1 



IPv4 address type 

SIDR- 

DM- 

7.1.1 

CR-7.2 


A delegated CA is 
able to create ROAs 

on behalf of its 

customers and 

store them in its 
repository. 



CR-7.2.1 



IPv4 address type 

SIDR- 

DM- 

7.2.1 

CR-7.3 


A delegated CA is 
able to 

delete/revoke an 

ROA that it has 

created for 

addresses that it 

holds from its own 
repository. 



CR-7.3.1 



IPv4 address type 

SIDR- 

DM- 

7.1.1 

CR-7.4 


A delegated CA is 
able to 

delete/revoke an 

ROA that it has 

created and is 
storing on behalf of 
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Capability 
Requirement 
(CR) ID 

Parent Requirement 

Sub-Requirement 1 

Sub-Requirement 2 

Test 

Case 



its customers from 
its own repository. 



CR-7.4.1 



IPv4 address type 

SIDR- 

DM- 

7.2.1 

CR-7.5 


A delegated CA is 
able to create ROAs 

for addresses that 

it holds that will 
expire as designed. 



CR-7.5.1 



IPv4 address type 

SIDR- 

DM- 

7.1.1 

CR-7.6 


A delegated CA is 
able to create ROAs 

on behalf of its 

customers that will 
expire as designed. 



CR-7.6.1 



IPv4 address type 

SIDR- 

DM- 

7.2.1 

CR-7.7 


ROAs that are 

stored in the 
delegated CA's 
repository are 
downloaded to the 
VCs that relying 
parties construct, 
validate, and 
maintain. 



CR-7.7.1 



IPv4 address type 

SIDR- 

DM- 

7.1.1 

& 

7.2.1 
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2739 

2740 

2741 

2742 

2743 

2744 

2745 

2746 

2747 

2748 


DRAFT 


Capability 
Requirement 
(CR) ID 

Parent Requirement 

Sub-Requirement 1 

Sub-Requirement 2 

Test 

Case 

CR-7.8 


The VRP 

information that is 
downloaded by 
routers from VCs 
using the RPKI-to- 
router protocol 
includes 

information 

derived from ROAs 

that are stored in 
the delegated CA's 
repository. 



CR-7.8.1 



IPv4 address type 

SIDR- 

DM- 

7.1.1 

& 

7.2.1 


E.3 Tests 

The remaining sub-sections provide the tests that have been designed to validate that the SIDR example 
implementation meets each of the SIDR functional requirements specified in Table E-1 above. Each test 
consists of multiple fields that collectively identify the objective of the test, the steps required to 
implement the test, and how to assess the results of the test. Table E-2 provides a template of a test 
case, including a description of each field in the test case. 

Unless otherwise specified, these tests are written under the assumption that the amount of time that 
elapses between any test step and the next is sufficient to allow modifications that are made to the 
global RPKI to propagate down to the VC and then to the RUT. This means that if an ROA is updated in 
one step of the test, the effects that this ROA has on the validation state of routes in the RUT's router 
information base will be evident in the next step of the test. 
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2749 


2750 

2751 

2752 

2753 

2754 

2755 

2756 

2757 

2758 

2759 

2760 

2761 

2762 

2763 

2764 


Table E-2 Test Case Fields 


Test Case Field 

Description 



Test Objective 

Lists the requirement being tested (as identified in the table of SIDR 
functional test requirements). Describes the objective of the test case. 

Preconditions 

The starting state of the test case. Preconditions indicate various starting 
state items, such as a specific capability configuration required or specific 
protocol and content. 

IPv4 or IPv6? 

States which type of 
addresses are being 
used. 

Test Harness or 

Hardware with Live 

RPKI? 

Indicates source of test 

data. 

Test Procedure 

The step-by-step actions required to implement the test case. A procedure 
may consist of a single sequence of steps or multiple sequences of steps 
(with delineation) to indicate variations in the test procedure. 

Expected Results 

The expected results for each variation in the test procedure, assuming 
that the test functions as intended. 

Actual Results 

As expected or the observed results. 

Additional Comments 
(If Needed) 



E.3.1 SIDR ROVTest Cases —Routes Received in BGP Updates 

During all harness tests, the RUT communicates the validation result of selected routes to an iBGP peer 
by using the Extended Community String specified in RFC 8097 or via the regular community string using 
the type 0x4300 and values 0-2, as specified in RFC 8097, only in 4-octet notation, rather than 8-octet 
notation. However, visual verification was used with appropriate show commands to verify the expected 
results with tests performed using hardware with live RPKI data stream. 

The route validation results, as well as the RPKI table within the RUT, will be retrieved and logged. For all 
tests, the commands used are as follows: 

■ Cisco: 

• To "Verify that this route is installed in the routing table" and "Verify that the RUT 
evaluates this route advertisement as valid, invalid, or not found," use: show ip bgp. 

• To "Verify that the RUT receives VRP information," use: show ip bgp rpki table. 

■ Juniper: 

• To "Verify that this route is installed in the routing table" and "Verify that the RUT 
evaluates this route advertisement as valid, invalid, or not found," use: show table. 
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2765 • To "Verify that the RUT receives VRP information," use: show validation database 

2766 E.3.1.1 Test Case: SIDR-ROV-1.1.1 and 1.1.2 


Test Objective 

Test SIDR Requirement CR-1.1. Show that the ROV-capable router correctly 


evaluates received routes in the following situation: The advertised route is 
initially evaluated as valid. The single ROA that had made the route valid is 
removed from the RPKI; there is no ROA that covers the route, so the route is re¬ 
evaluated as not found. 

{valid not found) 

Preconditions 

The testbed is configured with the topology and ASNs as depicted in the Testbed 
Architecture in Figure E-1 and Figure E-2. The router is set up to accept every BGP 
route, regardless of the validation state. No ROAs have been published that cover 
10.100.0.0/16. RUT is Router AS65501. The following configuration for Router 

AS65501 has been added: 

3 

Test 1-1-1 

Config.txt 

IPv4 or IPv6? 

Both Test Harness or Both 

Hardware with Live RPKI? 

Test 

Procedure 

1. AS 65511 publishes an ROA for its address space: (10.100.0.0/16, 16, AS65511). 

2. AS 65511 originates a BGP route advertisement for 10.100.0.0/16. 

3. Verify that the RUT receives VRP information. 

4. Verify that the RUT evaluates this route advertisement as valid. 

5. Verify that this route is installed in the routing table. 

6. AS 65511 removes the ROA published in Step 1 from the RPKI. 

7. Verify that the RUT evaluates this route advertisement as not found. 

For IPv6, use IP address FD10:100:100:l::/64 in place of 10.100.0.0/16. 

Expected 

Results 

IPv4 Results: Each of the expected results in Steps 3, 4, 5, and 7 above will be 
verified. 

Actual Results 

Test completed and functions as intended in Steps 3, 4, 5, and 7. 

Additional 

Comments 
(If Needed) 

Changes in the validation state of selected routes are also observed via IBGP traffic. 
Step 5 is observed by monitoring the incoming traffic on its IBGP peer. 
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2767 Test case SIDR-ROV-1.1.2 is identical to test case SIDR-ROV-1.1.1, except that IPv6 addresses are used 

2768 instead of IPv4 addresses. 

2769 Note: Test case SIDR-ROV-1.1.1 was also completed using the Cisco lOS-XR image running on VMware. 

2770 Using the same procedures, AS65501 was replaced by this Cisco lOS-XR router with the configuration of 

2771 the attached file: 



Test 1 - 1-1 

2yy2 Config-IOS-XR.txt 

2773 E.3.1.2 Test Case: SIDR-ROV-1.2.1 and 1.2.2 


Test Objective Test SIDR Requirement CR-1.2.1. Show that the ROV-capable router correctly 
evaluates received routes in the following situation; The advertised route is 
initially evaluated as valid. The single ROA that had made the route valid is 
removed from the RPKI. There is another ROA that covers the route, but the ASN 
in this ROA does not match that of the route's origin, so the route is re-evaluated 
as invalid. 

{valid -> invalid) 
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7. AS 65511 removes the ROA published in Step 1 from the RPKI. 

8. Verify that the RUT now evaluates the route advertisement for 10.100.0.0/16 
that originated from 65511 as invalid. 

For IPv6, use IP address FD10:100:100:l::/64 in place of 10.100.0.0/16. 

Expected 

Results 

Each of the expected results in Steps 4, 5, 6, and 8 above will be verified. 

Actual Results 

Test completed and functions as intended in Steps 4, 5, 6, and 8. 

Additional 

Comments 

(If Needed) 

Changes in the validation state of selected routes are also observed via iBGP traffic. 
Step 6 is validated by monitoring the incoming traffic on its iBGP peer. 


2774 Test case SIDR-ROV-1.2.2 is identical to test case SIDR-ROV-1.2.1, except that IPv6 addresses are used 

2775 instead of IPv4 addresses. 

2776 E.3.1.3 Test Case: SlDR-ROV-1.3.1 and 1.3.2 


Test Objective 

Test SIDR Requirement CR-1.3.1. Show that the ROV-capable router correctly 


evaluates received routes in the following situation; The advertised route is 
initially evaluated as valid. The single ROA that had made the route valid is 
removed from the RPKI. There is another ROA that covers the route, but its 
maximum prefix length is less than the prefix length of the route, so the route is 
re-evaluated as invalid. 

{valid invalid) 

Preconditions 

The testbed is configured with the topology, IP addressing scheme, and ASNs as 
depicted in the Testbed Architecture in Figure E-1 and Figure E-2. The router is set 
up to accept every BGP route, regardless of the validation state. 

IPv4 or IPv6? 

Both Test Harness or Both 

Hardware with Live RPKI? 

Procedure 

1. AS 65511 publishes an ROA for its address space: (10.100.0.0/16, 16, AS65511). 

2. AS 65511 publishes a second ROA for the same address space, but with a larger 
maximum length: (10.100.0.0/16, 24, AS65511). 

3. AS 65511 originates a BGP route advertisement for 10.100.8.0/24. 

4. Verify that the RUT receives VRP information. 

5. Verify that the RUT evaluates this route advertisement as valid. 
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6. Verify that this route is installed in the routing table. 

7. AS 65511 removes the ROA published in Step 2 from the RPKI. 

8. Verify that the RUT evaluates the route to 10.100.8.0/24 that was originated by 

AS 65511 as invalid. 

For IPv6, use IP address FD10:100:100:l::/64 in place of 10.100.0.0/16. 

Expected 

Results 

Each of the expected results in Steps 4, 5, 6, and 8 above will be verified. 

Actual Results 

Test completed and functions as intended in Steps 4, 5, 6, and 8. 

Additional 

Comments 
(If Needed) 

Changes in the validation state of selected routes are also observed via iBGP traffic. 
Step 6 is validated by monitoring the incoming traffic on its IBGP peer. 


Till Test case SIDR-ROV-1.3.2 is identical to test case SIDR-ROV-1.3.1, except that IPv6 addresses are used 

2778 instead of IPv4 addresses. 

2779 E.3.1A Test Case: SIDR-ROV-1.4.1 and 1.4.2 


Test Objective 

Test SIDR Requirement CR-1.4.1. Show that the ROV-capable router correctly 


evaluates received routes in the following situation; The advertised route is 
initially evaluated as valid. An ROA that had made the route valid is removed from 
the RPKI; there remains another ROA that matches the route, so the route still 
evaluates as valid. 

{valid valid) 

Preconditions 

The testbed is configured with the topology, IP addressing scheme, and ASNs as 
depicted in the Testbed Architecture in Figure E-1 and Figure E-2. The router is set 
up to accept every BGP route, regardless of the validation state. 

IPv4 or IPv6? 

Both Test Harness or Both 

Hardware with Live RPKI? 

Procedure 

1. AS 65511 publishes an ROA for its address space: (10.100.0.0/16, 16, AS65511). 

2. AS 65511 publishes a second ROA for the same address space, but with a larger 
maximum length: (10.100.0.0/16, 24, AS65511). 

3. AS 65511 originates a BGP route advertisement for 10.100.0.0/16. 

4. Verify that the RUT receives VRP information. 

5. Verify that the RUT evaluates this route advertisement as valid. 
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6. Verify that this route is installed in the routing table. 

7. AS 65511 removes the ROA published in Step 1 from the RPKI. 

8. Verify that the RUT still evaluates the route to 10.100.0.0/16 that AS 65511 


originated as valid. 

9. Verify that this route is still in the routing table. 

For IPv6, use IP address FD10:100:100:l::/64 in place of 10.100.0.0/16. 


Expected 

Results 

Each of the expected results in Steps 4, 5, 6, 8, and 9 above will be verified. 

Actual Results 

Test completed and functions as intended in Steps 4, 5, 6, 8, and 9. 

Additional 
Comments (If 
Needed) 

Changes in the validation state of selected routes are also observed via IBGP traffic. 
Steps 6 and 9 are validated by monitoring the incoming traffic on its IBGP peer. 


2780 Test case SIDR-ROV-1.4.2 is identical to test case SIDR-ROV-1.4.1, except that IPv6 addresses are used 

2781 instead of IPv4 addresses. 

2782 E.3.1.5 Test Case: SIDR-ROV-L5.1 and 1.5.2 


Test Objective Test SIDR Requirement CR-1.5.1. Show that the ROV-capable router correctly 
evaluates received routes in the following situation: The advertised route is 
initially evaluated as not found. An ROA that matches the route is added to the 
RPKI, so the route is re-evaluated as valid. 

{not found -> valid) 

Preconditions The testbed is configured with the topology, IP addressing scheme, and ASNs as 

depicted in the Testbed Architecture in Figure E-1 and Figure E-2 . The router is set 
up to accept every BGP route, regardless of the validation state. No ROAs have been 
published that cover 10.100.0.0/16. 


IPv4 or IPv6? 

Both 

Test Harness or 

Both 



Hardware with Live RPKI? 



Verify that there are no published ROAs that cover the route 10.100.0.0/16. 

AS 65511 originates a BGP route advertisement for 10.100.0.0/16. 

Verify that the RUT evaluates this route advertisement as not found. 

Verify that this route is installed in the routing table. 

AS 65511 publishes an ROA for its address space: (10.100.0.0/16, 16, AS65511). 


Procedure 

2 . 

3. 

4. 

5. 
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6. Verify that the RUT now evaluates the route to 10.100.0.0/16 that AS 65511 
originated as valid. 

7. Verify that this route is still in the routing table. 

For IPv6, use IP address FD10:100:100:l::/64 in place of 10.100.0.0/16. 

Expected 

Results 

Each of the expected results in Steps 1, 3, 4, 6, and 7 above will be verified. 

Actual Results 

Test completed and functions as intended in Steps 1, 3, 4, 6, and 7. 

Additional 

Comments 

(If Needed) 

Changes in the validation state of selected routes are also observed via iBGP traffic. 
Steps 1 and 3 are verified combined. 

Steps 4 and 7 are verified monitoring the incoming traffic via iBGP peer. 


2783 Test case SIDR-ROV-1.5.2 is identical to test case SIDR-ROV-1.5.1, except that IPv6 addresses are used 

2784 instead of IPv4 addresses. 

2785 E.3.1.6 Test Case: SIDR-ROV-1.6.1 and 1.6.2 


Test Objective 

Test SIDR Requirement CR-1.6.1. Show that the ROV-capable router correctly 


evaluates received routes in the following situation: The advertised route is 
initially evaluated as not found. An ROA that covers this route, but that has an 

ASN different from that of the route's origin, is added to the RPKI, so the route is 
re-evaluated as invalid. 

(NOT FOUND -> invalid) 

Preconditions 

The testbed is configured with the topology, IP addressing scheme, and ASNs as 
depicted in the Testbed Architecture in Figure E-1 and Figure E-2. The router is set 
up to accept every BGP route, regardless of the validation state. No ROAs have been 
published that cover 10.100.0.0/16. 

IPv4 or IPv6? 

Both Test Harness or Both 

Hardware with Live RPKI? 

Procedure 

1. Verify that there are no published ROAs that cover the route 10.100.0.0/16. 

2. AS 65511 originates a BGP route advertisement for 10.100.0.0/16. 

3. Verify that the RUT evaluates this route advertisement as not found. 

4. Verify that this route is installed in the routing table. 

5. AS 65511 publishes an ROA for its address space authorizing a different AS to 
originate addresses for it: (10.100.0.0/16, 16, AS65510). 
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6. Verify that the RUT now evaluates the route to 10.100.0.0/16 that AS 65511 
originated as invalid. 

7. Verify that this route is still in the routing table. 

For IPv6, use IP address FD10:100:100:l::/64 in place of 10.100.0.0/16. 

Expected 

Results 

Each of the expected results in Steps 1, 3, 4, 6, and 7 above will be verified. 

Actual Results 

Test completed and functions as intended in Steps 1, 3, 4, 6, and 7. 

Additional 

Comments 
(If Needed) 

Changes in the validation state of selected routes are also observed via iBGP traffic. 
Steps 1 and 3 are verified combined. 

Steps 4 and 7 are verified monitoring the incoming traffic via iBGP peer. 


2786 Test case SIDR-ROV-1.6.2 is identical to test case SIDR-ROV-1.6.1, except that IPv6 addresses are used 

2787 instead of IPv4 addresses. 

2788 E.3.1.7 Test Case: SIDR-ROV-1.7.1 and 1.7.2 


Test 

Test SIDR Requirement CR-1.7.1. Show that the ROV-capable router correctly 

Description 

evaluates received routes in the following situation; The advertised route is 
initially evaluated as invalid due to an ROA that covers this route, but that has an 
ASN different from that of the route's origin. A second ROA that matches this 
route is added to the RPKI, so the route is re-evaluated as valid. 

{invalid -> valid) 

Preconditions 

The testbed is configured with the topology, IP addressing scheme, and ASNs as 
depicted in the Testbed Architecture in Figure E-1 and Figure E-2. The router is set 
up to accept every BGP route, regardless of the validation state. 

IPv4 or IPv6? 

Both Test Harness or Both 

Hardware with Live RPKI? 

Procedure 

1. AS 65511 publishes an ROA for its address space that authorizes a different AS 
to originate addresses for it: (10.100.0.0/16, 16, AS65510). 

2. AS 65511 originates a BGP route advertisement for 10.100.0.0/16. 

3. Verify that the RUT receives VRP information. 

4. Verify that the RUT evaluates this route advertisement as invalid. 

5. Verify that this route is installed in the routing table. 

6. AS 65511 publishes an ROA for its address space: (10.100.0.0/16, 16, AS65511). 
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7. Verify that the RUT now evaluates the route to 10.100.0.0/16 that AS 65511 
originated as valid. 

8. Verify that this route is still in the routing table. 

For IPv6, use IP address FD10:100:100:l::/64 in place of 10.100.0.0/16. 

Expected 

Results 

Each of the expected results in Steps 3, 4, 5, 7, and 8 above will be verified. 

Actual Results 

Test completed and functions as intended in Steps 3, 4, 5, 7, and 8. 

Additional 

Comments 

(If Needed) 

Changes in the validation state of selected routes are also observed via iBGP traffic. 
Steps 5 and 8 are verified monitoring the incoming traffic via iBGP peer. 


2789 Test case SIDR-ROV-1.7.2 is identical to test case SIDR-ROV-1.7.1, except that IPv6 addresses are used 

2790 instead of IPv4 addresses. 

2791 E.3.1.8 Test Case: SIDR-ROV-1.8.1 and 1.8.2 


Test 

Test SIDR Requirement CR-1.8.1. Show that the ROV-capable router correctly 

Objective 

evaluates received routes in the following situation; The advertised route is initially 
evaluated as invalid due to the presence of one ROA that covers this route, but that 
has an ASN different from that of the route's origin. This is the only ROA that covers 
the route. It is deleted from the RPKI, so the route is re-evaluated as not found, 
{invalid -> not found) 

Preconditions 

The testbed is configured with the topology, IP addressing scheme, and ASNs as 
depicted in the Testbed Architecture in Figure E-1 and Figure E-2. The router is set up 
to accept every BGP route, regardless of the validation state. No ROAs have been 
published that cover 10.100.0.0/16. 

IPv4 or IPv6? 

Both Test Harness or Both 

Hardware with Live RPKI? 

Procedure 

1. AS 65511 publishes an ROA for its address space that authorizes a different AS to 
originate addresses for it: (10.100.0.0/16, 16, AS65510). 

2. AS 65511 originates a BGP route advertisement for 10.100.0.0/16. 

3. Verify that the RUT receives VRP information. 

4. Verify that the RUT evaluates this route advertisement as invalid. 

5. Verify that this route is installed in the routing table. 
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6. AS 65511 removes the ROA that it published in Step 1 from the RPKI. 

7. Verify that the RUT now evaluates the route to 10.100.0.0/16 that AS65511 
originated as not found. 

8. Verify that this route is still in the routing table. 

For IPv6, use IP address FD10:100;100:l::/64 in place of 10.100.0.0/16. 

Expected 

Results 

Each of the expected results in Steps 3, 4, 5, 7, and 8 above will be verified. 

Actual 

Results 

Test completed and functions as intended in Steps 3, 4, 5, 7, and 8. 

Additional 

Comments 
(If Needed) 

Changes in the validation state of selected routes are also observed via IBGP traffic. 
Steps 5 and 8 are verified monitoring the incoming traffic via iBGP peer. 


2792 Test case SIDR-ROV-1.8.2 is identical to test case SIDR-ROV-1.8.1, except that IPv6 addresses are used 

2793 instead of IPv4 addresses. 

2794 E.3.1.9 Test Case: SlDR-ROV-1.9.1 and 1.9.2 


Test 

Test SIDR Requirement CR-1.9.1. Show that the ROV-capable router correctly 

Objective 

evaluates received routes in the following situation: The advertised route is initially 
evaluated as invalid. There are two ROAs that cover this route, both of which have 
ASNs different from that of the route's origin. Only one of these ROAs is deleted 
from the RPKI, so the route still evaluates as invalid. 

{invalid -> invalid) 

Preconditions 

The testbed is configured with the topology, IP addressing scheme, and ASNs as 
depicted in the Testbed Architecture in Figure E-1 and Figure E-2. The router is set up 
to accept every BGP route, regardless of the validation state. 

IPv4 or IPv6? 

Both Test Harness or Both 

Hardware with Live RPKI? 

Procedure 

1. AS 65511 publishes an ROA for its address space that authorizes a different AS to 
originate addresses for it: (10.100.0.0/16, 16, AS65510). 

2. AS 65511 publishes a second ROA for its address space that authorizes a second 

AS to originate addresses for it: (10.100.0.0/16, 16, AS65509). 

3. AS 65511 originates a BGP route advertisement for 10.100.0.0/16. 
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4. Verify that the RUT receives VRP information. 

5. Verify that the RUT evaluates this route advertisement as invalid. 

6. Verify that this route is installed in the routing table. 

7. AS 65511 removes the ROA that it published in Step 1 from the RPKI. 

8. Verify that the RUT still evaluates the route to 10.100.0.0/16 that AS 65511 had 
originated as invalid. 

9. Verify that this route is still in the routing table. 

For IPv6, use IP address FD10;100;100:l::/64 in place of 10.100.0.0/16. 

Expected 

Results 

Each of the expected results in Steps 4, 5, 6, 8, and 9 above will be verified. 

Actual 

Results 

Test completed and functions as intended in Steps 4, 5, 6, 8, and 9. 

Additional 

Comments 
(If Needed) 

Changes in the validation state of selected routes are also observed via iBGP traffic. 
Steps 6 and 9 are verified monitoring the incoming traffic via iBGP peer. 


2795 Test case SIDR-ROV-1.9.2 is identical to test case SIDR-ROV-1.9.1, except that IPv6 addresses are used 

2796 instead of IPv4 addresses. 

2797 E.3.1.10 Test Case: SIDR-ROV-1.10.1 ancll.10.2 


Test Objective 

Test SIDR Requirement CR-1.4.1. Show that the ROV-capable router correctly 


evaluates received routes in the following situation: The advertised route is 
initially evaluated to be invalid due to the fact that it contains AS_SET, even though 
there is an ROA that covers the route and that has a maximum length greater than 
the route's prefix. The route is re-announced, this time without the AS_SET in the 
path. The route in the second advertisement is evaluated as valid. 

{invalid valid) 

Preconditions 

The testbed is configured with the topology, IP addressing scheme, and ASNs as 
depicted in the Testbed Architecture in Figure E-1 and Figure E-2. The router is set up 
to accept every BGP route, regardless of the validation state. The following 
configuration for Routers AS65501, AS65504, AS65507, and AS65511 has been 
added: 
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g 

Testi 1 10-1.txt 

IPv4 or IPv6? 

Both Test Harness or Both 

Hardware with Live RPKI? 

Procedure 

1. AS 65511 publishes an ROA for (10.0.0.0/8, 8, AS65511). 

2. AS 65507 publishes an ROA for its address space: (10.60.0.0/16, 16, AS65507). 

3. AS 65504 publishes an ROA for its address space: (10.40.0.0/16, 16, AS65504). 

4. The router in AS 65511 is configured to aggregate routes from AS 65504 and 

AS 65507 and advertise the aggregate route with the AS_SET segment. 

5. AS 65507 originates a BGP route advertisement for 10.60.0.0/16, and AS 65504 
originates a BGP route advertisement for 10.40.0.0/16, causing AS 65511 to 
aggregate these two announcements and send out a BGP route advertisement 
for 10.0.0.0/8 that contains AS_SET (AS65507, AS65504) as its origin. 

6. Verify that the RUT evaluates this route to 10.0.0.0/8 as invalid. 

7. Verify that this route is installed into the routing table. 

8. Now change the configuration on AS 65511 so that it will no longer advertise the 
AS_SET segment. 

9. AS 65511 originates a BGP route advertisement for 10.0.0.0/8. 

10. Verify that the RUT evaluates this route advertisement as valid. 

11. Verify that that this route is still in the routing table. 

For IPv6, use IP address FD40:40:40:40::68/64, FD60:6060:6060:60:;l/64, 

FD10:100:100:l::l/64. 

Expected 

Results 

Each of the expected results in Steps 6, 7, 10, and 11 above will be verified. 

Actual Results 

In a few cases. Step 6 did not have the expected result. 

We found that, in some implementations, the aggregated route/prefix 10.0.0.0/8, 
65511 (65504, 65507) was evaluated as nof/ound instead of invalid, as stipulated in 

RFC 8210. 

Additional 

Comments 
(If Needed) 

Most commercially provided platforms did validate routes containing AS_SET as not 
found, whether covering ROAs exist or not. 
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2798 Test case SIDR-ROV-1.10.2 is identical to test case SIDR-ROV-1.10.1, except that IPv6 addresses are used 

2799 instead of IPv4 addresses. 


2800 E.3.2 SIDR ROVTest Cases - Local Static Routes Redistributed into BGP 

2801 E.3.2.1 Test Case: SIDR-ROV-2.1.1, 2.1.2, and 2.1.3 


Test Objective Test SIDR Requirement CR-2.1.1. Show that the ROV-capable router correctly 

evaluates received routes in the following situation; A route is redistributed into 
BGP from a locally defined static route. This route is initially evaluated as valid. 

The single ROA that had made the route valid is removed from the RPKI. There is 
another ROA that covers the route, but the ASN in this ROA does not match that of 
the route's origin, so the route is re-evaluated as invalid, {valid invalid) 


(This test is analogous to Test SIDR-ROV-1.2.1, but this test evaluates a route that 
has been redistributed into BGP from a static route, rather than a route that was 
received as a BGP update.) 


Preconditions The testbed is configured with the topology, IP addressing scheme, and ASNs as 
depicted in the Testbed Architecture in Figure E-2 . The router is set up to accept 
every BGP route, regardless of the validation state. No ROAs have been published 
that cover 10.10.0.0/16. The following configuration for Router AS65501 has been 
added: 



Test 2-1-1 
Config.txt 


IPv4 or IPv6? 

Both 

Test Harness or 

Hardware with Live RPKI 



Hardware with Live RPKI? 



Configure the AS 65501 router to redistribute static routes into BGP. 

AS 65501 publishes an ROA for its address space: (10.10.0.0/16, 16, AS65501). 
AS 65501 publishes a second ROA for the same address space that authorizes a 
different AS to originate addresses for it: (10.10.0.0/16, 16, AS65505). 

At the AS 65501 router, configure a static route 10.10.1.0/16. 

Verify that the RUT (i.e., the AS 65501 router) evaluates the 10.10.1.0/16 route 
as valid, (show ip bgp) 

Verify that this route is installed in the routing table, (show ip route) 

AS 65501 removes the ROA published in Step 2 from the RPKI. 

Verify that the RUT now evaluates the 10.10.1.0/16 route as invalid. 


Procedure 

2 . 

3. 

4. 

5. 

6. 

7. 

8. 
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2802 

2803 

2804 


2805 

2806 

2807 

2808 


2809 

2810 



9. Verify that this route is still in the routing table. 


For IPv6, use IP address FD10:10:10:10::/64 in place of 10.10.0.0/16. 

Expected 

Results 

Each of the expected results in Steps 5, 6, 8, and 9 above will be verified. 

Actual Results 

Test completed and functions as expected. 

Additional 
Comments (If 
Needed) 

We noticed that, while some vendors' implementation evaluates local routes 
(e.g., prefixes learned from static, IGP, and connected routes) as valid, others assess 
the same routes as unverified. 


Test case SIDR-ROV-2.1.2 is identical to test case SIDR-ROV-2.1.1, except that IPv6 addresses are used 
instead of IPv4 addresses. The following configuration for Routers AS65501 and AS65505 was added 
prior to running the test: 



Test2 1 IB 
Config.txt 


Test case SIDR-ROV-2.1.3 is identical to test case SIDR-ROV-2.1.1, except that the Cisco lOS XR virtual 
router was used instead of the Cisco 7206 physical router. The following configuration for the Cisco lOS 
XR virtual router was added prior to running the test: 



Test 2 11 XR 
Config.txt 

E.3.2.2 Test Cose: SIDR-ROV-2.2.1 and 2.2.2 


Test Objective Test SIDR Requirement CR-2.2.1. Show that the ROV-capable router correctly 

evaluates received routes in the following situation; A route is redistributed into 
BGP from a locally defined static route. This route is initially evaluated as not 
found. An ROA that matches the route is added to the RPKI, so the route is re¬ 
evaluated as valid, {not found -> valid) 

(This test is analogous to Test SIDR-ROV-1.5.1, but this test evaluates a route that 
has been redistributed into BGP from a static route, rather than a route that was 
received as a BGP update.) 
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Preconditions The testbed is configured with the topology, IP addressing scheme, and ASNs as 
depicted in the Testbed Architecture in Figure E-1 . The router is set up to accept 
every BGP route, regardless of the validation state. No ROAs have been published 
that cover the route 10.10.1.0/16. The following configuration for Routers AS65501 
and AS65505 has been added: 



Test 2-2-1 
Config.txt 


IPv4 or IPv6? 

Both 

Test Harness or 

Hardware with Live RPKI 



Hardware with Live RPKI? 



Configure the AS 65501 router to redistribute static routes into BGP. 

Verify that there are no published ROAs that cover the route 10.10.1.0/16. 

At the AS 65501 router, configure a static route 10.10.1.0/16. 

Verify that the RUT (i.e., the AS 65501 router) evaluates this route as not found. 
(show ip bgp) 

Verify that this route is installed in the routing table, (show ip route) 

AS 65501 publishes an ROAfor its address space: (10.10.0.0/16, 16, AS 65501). 
Verify that the RUT (i.e., the AS65501 router) re-evaluates its static route 
10.10.1.0/16 as valid. 

Verify that this route is still in the routing table. 


For IPv6, use IP address FD10:10:10:10::/64 in place of 10.10.0.0/16. 


Expected 

Results 

Each of the expected results in Steps 4, 5, 7, and 8 above will be verified. 

Actual Results 

Test completed and functions as expected. 

Additional 

None 


Comments (If 
Needed) 


Procedure 

2 . 

3. 

4. 

5. 

6. 

7. 

8. 


2811 Test case SIDR-ROV-2.2.2 is identical to test case SIDR-ROV-2.2.1, except that IPv6 addresses are used 

2812 instead of IPv4 addresses. The following configuration for Router AS65505 was updated prior to running 

2813 the test: 
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Test 2 2 IB 
Config.txt 


2815 E.3.2.3 Test Case: SIDR-ROV-2.3.1 and 2.3.2 


Test Objective Test SIDR Requirement CR-2.3.1. Show that the ROV-capable router correctly 

evaluates received routes in the following situation: A route is redistributed into 
BGP from a locally defined static route. This route is initially evaluated as not 
found. An ROA that covers this route, but that has an ASN different from that of 
the route's origin, is added to the RPKI, so the route is re-evaluated as invalid, {not 
found invalid) 


(This test is analogous to Test SIDR-ROV-1.6.1, but this test evaluates a route that 
has been redistributed into BGP from a static route, rather than a route that was 
received as a BGP update.) 

Preconditions The testbed is configured with the topology, IP addressing scheme, and ASNs as 

depicted in the Testbed Architecture in Figure E-1 and Figure E-2 . The router is set 
up to accept every BGP route, regardless of the validation state. No ROAs have been 
published that cover the route 10.10.1.0/16. The following configuration for Routers 
AS65501 and AS65505 has been added: 



Test 2 3 1 
Config.txt 


IPv4 or IPv6? 

Both 

Test Harness or 

Both 



Hardware with Live RPKI? 



Configure the AS 65501 router to redistribute static routes into BGP. 

Verify that there are no published ROAs that cover the route 10.10.1.0/16. 

At the AS 65501 router, configure a static route 10.10.1.0/16. 

Verify that the RUT (i.e., the BGP router at AS 65501) evaluates this route as not 
found, (show ip bgp) 

Verify that this route is installed in the routing table, (show ip route) 

AS 65501 publishes an ROA for its address space authorizing a different AS to 
originate addresses for it: (10.10.0.0/16, 16, AS65505). 

Verify that the RUT (i.e., the BGP router at AS 65501) re-evaluates this route 
10.10.1.0/16 as/nvo//c/. 


Procedure 

2 . 

3. 

4. 

5. 

6. 

7. 
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2816 

2817 

2818 

2819 

2820 
2821 



8. Verify that this route is still in the BGP routing table. 

For IPv6, use IP address FD10:10:10:10::/64 in place of 10.10.0.0/16. 

Expected 

Results 

Each of the expected results in Steps 4, 5, 7, and 8 above will be verified. 

Actual Results 

Test completed and functions as expected. 

Additional 
Comments (If 
Needed) 

None 


Test case SIDR-ROV-2.3.2 is identical to test case SIDR-ROV-2.3.1, except that IPv6 addresses are used 
instead of IPv4 addresses. The following configuration for Router AS65505 was updated prior to running 
the test: 



Test2 3 IB 
Config.txt 


E.3.3 SIDR ROVTest Cases — Routes Redistributed into BGPfrom an IGP 


E.3.3.1 Test Case: SIDR-ROV-3.1.1 

Test Objective 

Test SIDR Requirement CR-2.4.1. Show that the ROV-capable router correctly 
evaluates received routes in the following situation; A route is redistributed into 
BGP from an IGP. This route is initially evaluated as valid. The single ROA that had 
made the route valid is removed from the RPKI; there is no ROA that covers the 
route, so the route is re-evaluated as not found, {valid -> not found) 

(This test is analogous to Test SIDR-ROV-1.1.1, but this test evaluates a route that 
has been redistributed into BGP from an IGP, rather than a route that was 
received as a BGP update.) 

Preconditions 

The testbed is configured with the topology, IP addressing scheme, and ASNs as 
depicted in the Testbed Architecture in Figure E-1 and Figure E-2. The router is set 
up to accept every BGP route, regardless of the validation state. No ROAs have been 
published that cover the route 10.10.0.0/16. The following configuration for Routers 
AS65501 and AS65505 has been added: 
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& 

Test 3-1-1 

Config .txt 



IPv4 or IPv6? 

IPv4 

Test Harness or 

Hardware with Live RPKI? 

Both 


Configure the AS 65501 router to redistribute routes from an IGP that is in use 
in AS 65501 into BGP. 

AS 65501 publishes an ROA for its address space: (10.10.0.0/16, 16, AS 65501). 
Create route 10.10.2.0/16 in the IGP that is running on AS 65501. This route 
should get redistributed into BGP. 

Verify that the RUT (i.e., the BGP router in AS 65501) evaluates this route as 
valid, (show ip bgp) 

Verify that this route is installed in the routing table, (show ip route) 

AS 65501 removes the ROA published in Step 2 from the RPKI. 

Verify that the RUT (i.e., the BGP router in AS 65501) re-evaluates this route 
10.10.2.0/16 as not found. 

Verify that this route is still in the BGP routing table. 

For IPv6, use IP address FD10:10:10:10::/64 in place of 10.10.0.0/16. 

Expected Each of the expected results in Steps 4, 5, 7, and 8 above will be verified. 

Results 


Actual Results Test completed and functions as expected. 


Additional None 
Comments (If 
Needed) 


2822 E.3.3.2 Test Case: SIDR-ROV-3.2.1 


Test Objective Test SIDR Requirement CR-2.5.1. Show that the ROV-capable router correctly 

evaluates received routes in the following situation: A route is redistributed into 
BGP from an IGP. This route is initially evaluated as invalid due to an ROA that 
covers this route, but that has an ASN different from that of the route's origin. A 
second ROA that matches this route is added to the RPKI, so the route is re¬ 
evaluated as valid, {invalid valid) 


Procedure 

2 . 

3. 

4. 

5. 

6. 

7. 

8. 


NIST SP 1800-14B: Protecting the Integrity of Internet Routing 


138 














DRAFT 



(This test is analogous to Test SIDR-ROV-1.7.1, but this test evaluates a route that 
has been redistributed into BGP from an IGP, rather than a route that was received 
as a BGP update.) 

Preconditions 

The testbed is configured with the topology, IP addressing scheme, and ASNs as 
depicted in the Testbed Architecture in Figure E-1 and Figure E-2. The router is set 
up to accept every BGP route, regardless of the validation state. The following 
configuration for Routers AS65501 and AS65505 has been added: 

Test 3 -2-1 

Config.txt 

IPv4 or IPv6? 

IPv4 Test Harness or Both 

Hardware with Live RPKI? 

Procedure 

1. Configure the AS 65501 router to redistribute routes from an IGP that is in use in 

AS 65501 into BGP. 

2. AS 65501 publishes an ROA for its address space that authorizes a different AS to 
originate addresses for it: (10.10.0.0/16, 16, AS65505). 

3. Create route 10.10.2.0/16 in the IGP that is running on AS 65501. This route 
should get redistributed into BGP. 

4. Verify that the RUT (i.e., the BGP router in AS 65501) evaluates this route as 
invalid, (show ip bgp) 

5. Verify that this route is installed in the routing table, (show ip route) 

6. AS 65501 publishes an ROA for its address space: (10.10.0.0/16, 16, AS65501). 

7. Verify that the RUT (i.e., the BGP router in AS 65501) re-evaluates this route 
10.10.2.0/16 as valid. 

8. Verify that this route is still in the routing table. 

For IPv6, use IP address FD10:10:10:10::/64 in place of 10.10.0.0/16. 

Expected 

Results 

Each of the expected results in Steps 4, 5, 7, and 8 above will be verified. 

Actual Results 

Test completed and functions as expected. 

Additional 
Comments (If 
Needed) 

None 
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2823 E.3.3.3 Test Case: SIDR-ROV-3.3.1 


Test Objective Test SIDR Requirement CR-2.6.1. Show that the ROV-capable router correctly 

evaluates received routes in the following situation; A route is redistributed into 
BGP from an IGP. This route is initially evaluated as invalid due to the presence of 
one ROA that covers this route, but that has an ASN different from that of the 
route's origin. This is the only ROA that covers the route. It is deleted from the 
RPKI, so the route is re-evaluated as not found, {invalid not found) 


(This test is analogous to Test SIDR-ROV-1.8.1, but this test evaluates a route that 
has been redistributed into BGP from an IGP, rather than a route that was 
received as a BGP update.) 


Preconditions The testbed is configured with the topology, IP addressing scheme, and ASNs as 

depicted in the Testbed Architecture in Figure E-1 and Figure E-2 . The router is set 
up to accept every BGP route, regardless of the validation state. No ROAs have been 
published that cover 10.10.0.0/16. The following configuration for Routers AS65501 
and AS65505 has been added: 



Test 3 3 1 
Config.txt 


IPv4 or IPv6? 

IPv4 

Test Harness or 

Both 



Hardware with Live RPKI? 



Configure the AS 65501 router to redistribute routes from an IGP that is in use 
in AS 65501 into BGP. 

AS 65501 publishes an ROA for its address space that authorizes a different AS 
to originate addresses for it: (10.10.0.0/16, 16, AS65505). There are no other 
published ROAs that cover the route 10.10.0.0/16. 

Create route 10.10.2.0/16 in the IGP that is running on AS 65501. This route 
should get redistributed into BGP. 

Verify that the RUT (i.e., the BGP router in AS 65501) evaluates this route as 
invalid, (show ip bgp) 

Verify that this route is installed in the routing table, (show ip route) 

AS 65501 removes the ROA that it published in Step 2 from the RPKI. 

Verify that the RUT (i.e., the BGP router in AS 65501) re-evaluates this route 
10.10.2.0/16 as not found. 

Verify that this route is still in the routing table. 


Procedure 

2 . 

3. 

4. 

5. 

6. 

7. 

8. 
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For IPv6, use IP address FD10:10:10:10::/64 in place of 10.10.0.0/16. 

Expected 

Results 

Each of the expected results in Steps 4, 5, 7, and 8 above will be verified. 

Actual Results 

Test completed and functions as expected. 

Additional 
Comments (If 
Needed) 

None 


2824 E.3.4 iBGP Testing 

2825 E.3.4.1 Test Case: SIDR-ROV-4.1.1 


Test Objective 

Test SIDR Requirement CR-4.1. Show that the ROV-capable router correctly 


implements its policy to treat locally defined iBGP routes differently from other 
iBGP routes. In particular, show that the router can be configured to drop invalid 
routes, unless the route is a locally generated iBGP or a locally defined static 
route. Define two route prefixes in iBGP: Prefix A, which is locally generated, and 
Prefix B, which is not. Define Prefix C, which is an eBGP route. Define a static 
route, D. Ensure that all four routes will be evaluated and marked as invalid due 
to having exactly one ROA that covers each route, but that ROA has an ASN 
different from that of the route's origin. Configure routing policy such that 

Prefixes A and D (which are locally generated) will not be dropped. Validate that 
Prefixes A and D are inserted into the routing table, whereas Prefixes B and C are 

not. 

This test is similar to Test SIDR-ROV-2.3.1, but, in this test, the invalid non-locally 
defined static route that evaluates as invalid is dropped. It is also similar to Test 
SIDR-ROV-2.5.1, but, in this test, the invalid non-locally generated iBGP route that 
evaluates as invalid is dropped. 

Preconditions 

The testbed is configured with the topology, IP addressing scheme, and ASNs as 
depicted in the Testbed Architecture in Figure E-2. The router under test is 
configured with a policy of discarding invalid routes, unless those invalid routes are 
locally generated iBGP or locally defined static routes. There is at least one iBGP 
route that is not locally generated. The following configuration for Routers AS65501 
and AS65501i has been added: 
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& 

Test 4-1-1 

Config.txt 



IPv4 or IPv6? 

Both 

Test Harness or 

Hardware with Live RPKI? 

Hardware with Live RPKI 


Procedure 


Expected 

Results 


1. Configure the AS 65501 router to redistribute routes from an IGP that is in use 
in AS 65501 into BGP. 

2. Configure the AS 65501 router to redistribute static routes into BGP. 

3. Verify that there are no published ROAs that cover the prefix 10.10.0.0/16. 

4. AS 65501 publishes an ROA for its address space that authorizes AS 65505 to 
originate addresses for it: (10.10.0.0/16, 16, AS65505). 

5. Assume that route 10.10.2.0/16 is a route that was not locally generated, but 
ensure that it is being advertised in the IGP. (This route should get redistributed 
into BGP.) 

6. AS 65503 originates a BGP update for route 10.10.3.0/16. 

7. Generate local route 10.10.4.0/16 in the IGP that is running on AS 65501. (This 
route should get redistributed into BGP.) 

8. At the AS 65501 router, configure a static route 10.10.5.0/16. (This route should 
get redistributed into BGP.) 

9. Verify that the RUT (i.e., the BGP router in AS 65501) evaluates all four of the 
above routes as invalid (show ip bgp): 

a. 10.10.0.0/16 = Static 

b. 10.20.0.0/16 = eBGP 

c. 10.30.0.0/16 = IGP (RIPv2) 

d. 10.40.0.0/16 = Local (Connected) 

10. Verify that the first two of the above routes are not installed in the routing 
table and that the invalid routes are logged, (show ip route): 

a. 10.20.0.0/16 

b. 10.30.0.0/16 

11. Verify that the last two routes above are installed in the routing table: 

a. 10.10.40.0/16 

b. 10.10.5.0/16 


For IPv6, use FD10:10:10:10::/64, FD20:20:20:l::l/64, FD30:30:30:l::l/64, 
FD40:40:40:l::l/64. 
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Actual Results 

Vendor implementation varies. Certain vendors present all local routes and prefixes 
as vaiid, while others show them as unverified. 

Additional 
Comments (If 
Needed) 

Whereas RFC 6810 stipulates that routes or prefixes learned locallv (IGP, static and 
connected) should be designated as not found, vendor implementation variables 
interpret them as either unverified or valid. 

2826 E.3.4.2 Test Case: SIDR-ROV-4.2.1 

Test Objective 

Examine RPKI validation using eBGP, IGP, static and local network routes within 
an iBGP network by using a single, but shared, VC within the iBGP peers. 


Preconditions The testbed is configured with the topology, IP addressing scheme, and ASNs as 
depicted in the Testbed Architecture in Figure E-2 . 

AS 65511 is connected to AS 65501, and AS 65501 consists of two routers speaking 
iBGP. The edge router is connected to AS 65511 via eBGP and labeled AS65501-R1-1 
and the iBGP peer AS65501i-Rl-2. 

The RPKI VC 1 contains all used IP prefixes (10.10.0.0/16, 10.20.0.0/16, 

10.30.0.0/16, and 10.40.0.0/16), but assigned to origin AS 65509. The outcome 
should result in invalid based on the validation algorithm. 

Note: All routers are configured to NOT drop invalid. 

Traffic A: 10.20.0.0/16 is a route originated by AS 65511. 

Traffic B: There are three routes: one learned via IGP (10.30.0.0/16), another via 
static (10.10.0.0/16), and the third via local (10.40.0.0/16) network. 

AS65501-R1-1: Configure connection to RPKI VC 1, NO Extended Community String. 
AS65501i-Rl-2: Configure router as plain BGP (no RPKI). 

The following configuration for Routers AS65501 and AS65501i was added: 


Test 4 2 1 
Config.txt 


IPv4 or IPv6? 

Both 

Test Harness or 

Hardware with Live RPKI 



Hardware with Live RPKI? 



Procedure 


1. Configure the AS 65511 router to forward Traffic A to AS 65501. 

2. Configure AS 65501 to redistribute Traffic B into BGP. 
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3. AS65501-R1-1: Verify that the router contains Traffic A and B. 

4. AS65501-R1-1: Verify that the router contains RVPs in the RPKI table. 

5. AS65501-R1-1: Verify that the router validated Traffic A as invalid. 

6 . As65501-Rl-1: Verify that the router validated Traffic B as either invalid or not 
found. 

7. AS65501-R1-1: Send Traffic A and B to AS65501i-Rl-2. 

8 . AS65501i-Rl-2: Verify that the router does not contain the RPKI table or that 
the table is empty. 

9. AS65501i-Rl-2: Verify the receipt of Traffic A and B and that NO validation state 
is assigned. 

For IPv6, use FD10:10:10:10::/64, FD20:20:20:l::l/64, FD30:30:30:l::l/64, 

FD40:40:40:l::l/64. 

Expected Each of the expected results in Steps 3, 4, 5, 6, 8, and 9 above will be verified. 

Results 


Actual Results Vendor implementation varies. Certain vendors present all local routes and prefixes 
as valid, while others show them as unverified. 

Additional Whereas RFC 6810 stipulates that routes or prefixes learned locally (IGP, static, and 

Comments connected) should be designated as not found, vendor implementation variable 
(If needed) interprets them as either unverified or valid. 


2827 Test case SIDR-ROV-4.2.2 is identical to test case SIDR-ROV-4.2.1, except a Juniper router was used 

2828 instead of a Cisco router for Router AS65501i. The following configuration for Routers AS65501 and 

2829 AS65501i was updated prior to running the test: 


2830 



Test 4-2-1 Juniper 
Config.txt 


2831 E.3.4.3 Test Case: SIDR-ROV-4.3.1 


Test Objective Examine RPKI validation by using eBGP, IGP, static, and local network routes 
within an iBGP network using one shared VC within the iBGP peers without 
Extended Community Strings configuration. 


Preconditions The testbed is configured with the topology, IP addressing scheme, and ASNs as 
depicted in the Testbed Architecture in Figure E-2 . 
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AS 65511 is connected to AS 65501, and AS 65501 consists of two routers speaking 
iBGP. The edge router is connected to AS 65511 via eBGP and labeled AS65501-R1-1 
and the iBGP peer AS65501i-Rl-2. 

The RPKI VC 1 contains all used IP prefixes (10.10.0.0/16, 10.20.0.0/16, 

10.30.0.0/16, and 10.40.0.0/16), but assigned to origin AS 65509. The outcome 
should result in invalid based on the validation algorithm. 

All routers are configured to NOT drop invalid. 

Traffic A is a route originated by AS 65501. 

Traffic B has three routes: one learned via IBGP network, one via static network, 
and one via local network. 

Rl-1: Configure connection to RPKI VC 1, NO Extended Community String. 

Rl-2: Configure connection to RPKI VC 1. 

The following configuration for Routers AS65501 and AS65501i was added: 



Test 4 3 1 
Config.txt 


IPv4 or IPv6? 

Both 

Test Harness or 

Hardware with Live RPKI 



Hardware with Live RPKI? 



Procedure 

1 . 

Configure the AS 65505 router to redistribute Traffic A to AS 65501. 

2 . 

Configure AS 65501 to redistribute Traffic B. 


3. 

Rl-1: Verify that the router contains Traffic A and B. 


4. 

Rl-1: Verify tha the router contains RVPs in the RPKI table. 


5. 

Rl-1: Verify that the router validated Traffic A as invalid. 


6 . 

Rl-1: Verify that the router validated Traffic B as either invaiid or not found. 


7. 

Rl-1: Send Traffic A and B to Rl-2 WITHOUT Extended Community String. 


8 . 

Rl-2: Verify that the router contains RVPs in the RPKI table. 


9. 

Rl-2: Verify the receipt of Traffic A and B and that the validation state is 
assigned to either invalid or not found. 


For IPv6, use FD10:10:10:10::/64, FD20:20:20:l::l/64, FD30:30:30:l::l/64, 
FD40:40:40:l::l/64. 


Expected Each of the expected results in Steps 3, 4, 5, 6, and 8 above will be verified. 

Results 
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2832 

2833 

2834 


2835 

2836 


Actual Results 

Vendor implementation varies. Certain vendors present all local routes and prefixes 
as valid, while others show them as unverified. 

Additional 

Comments 
(If Needed) 

Whereas RFC 6810 stipulates that routes or prefixes learned locallv (IGP, static, and 
connected) should be designated as not found, vendor implementation variable 
interprets them as either unverified or valid. 


Test case SIDR-ROV-4.3.2 is identical to test case SIDR-ROV-4.3.1, except a Juniper router was used 
instead of a Cisco router for Router AS65501i. The following configuration for Routers AS65501 and 
AS65501i was updated prior to running the test: 



Test 4-3-1 Juniper 
Config.txt 

E.3.4.4 Test Case: SIDR-ROV-4.4.1 


Test Objective Examine RPKI validation by using eBGP, IGP, static, and local network routes within 
an iBGP network using one shared VC within the iBGP peers. (With Extended 
Community Strings) 


Preconditions The testbed is configured with the topology, IP addressing scheme, and ASNs as 
depicted in the Testbed Architecture in Figure E-2 . 

AS 65511 is connected to AS 65501, and AS 65501 consists of two routers speaking 
iBGP. The edge router is connected to AS 65511 via eBGP and labeled AS65501-R1-1 
and the iBGP peer AS65501i-Rl-2. 

The RPKI VC 1 contains all used IP prefixes (10.10.0.0/16, 10.20.0.0/16, 10.30.0.0/16, 
and 10.40.0.0/16), but assigned to origin AS 65509. The outcome should result in 
invalid based on the validation algorithm. 

All routers are configured to NOT drop invalid. 

Traffic A is a route originated by AS 65501. 

Traffic B has three routes: one learned via IBGP network, one via static network, and 
one via local network. 

Rl-1: Configure connection to RPKI VC 1, enable Extended Community String. 

Rl-2: Configure router as plain BGP (no RPKI). 
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The following configuration for Routers AS65501 and AS65501i was added: 



Test 4-4 1 
Config.txt 


IPv4 or IPv6? 

Both 

Test Harness or 

Hardware with Live RPKI 



Hardware with Live RPKI? 



Configure the AS 65511 router to send eBGP Traffic A to AS 65501. 

Configure AS 65501 to redistribute Traffic B. 

Rl-1: Verify that the router contains Traffic A and B. 

Rl-1: Verify that Rl-1 contains RVPs in the RPKI table. 

Rl-1: Verify that the router validated Traffic A as invalid. 

Rl-1: Verify that the router validated Traffic B as either invalid or not found. 

Rl-1: Send Traffic A and B to Rl-2 with Extended Community String. 

Rl-2: Verify that the router does not contain the RPKI RVP table or that the table 
is empty. 

Rl-2: Verify the receipt of Traffic A and B and that no validation state is assigned. 


For IPv6, use FD10:10:10:10::/64, FD20:20:20:l::l/64, FD30:30:30:l::l/64, 
FD40:40:40:l::l/64. 


Expected 

Results 

Each of the expected results in Steps 3, 4, 5, 6, 8, and 9 above will be verified. 

Actual Results 

Vendor implementation varies. Certain vendors present all local routes and prefixes 
as vaiid, while others show them as unverified. 

Additional 

Comments 
(If Needed) 

Whereas RFC 6810 stipulates that routes or prefixes learned locallv (IGP, static, and 
connected) should be designated as not found, vendor implementation variable 
interprets them as either unverified or valid. 


Procedure 

2 . 

3. 

4. 

5. 

6. 

7. 

8. 

9. 


2837 Test case SIDR-ROV-4.4.2 is identical to test case SIDR-ROV-4.4.1, except a Juniper router was used 

2838 instead of a Cisco router for Router AS65501i. The following configuration for Router AS65501i was 

2839 updated prior to running the test: 



Test 4-4-1 Juniper 
2840 Config.txt 
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2841 E.3.4.5 Test Case: SIDR-ROV-4.5.1 


Test Objective Examine RPKI validation by using eBGP, IGB, static, and local network routes within 
an iBGP network using two distinct VCs (VCs 1 and 2) within the iBGP peers while 
enabling Extended Community String. 

Preconditions The testbed is configured with the topology, IP addressing scheme, and ASNs as 
depicted in the Testbed Architecture in Figure E-2 . 

AS 65511 is connected to AS 65501, and AS 65501 consists of two routers speaking 
iBGP. 

The edge router connected to AS 65511 is labeled Rl-1, and the iBGP peer to 
AS65501-R1-1 is labeled AS65501i-Rl-2. 

The RPKI VC 1 contains all used IP prefixes, but for origin 65509. The RPKI VC 2 
contains all used IP prefixes of Traffic A with origin 65511, and IP prefixes of Traffic B 
with origin 65501. 

VC 1 should result in invalid of all routes in Rl-1, and VC 2 will result in valid of all 
routes in Rl-2, if validated using the RPKI validation algorithm. 

All routers are configured to NOT drop invalid. 

Traffic A is a route originated by AS 65511. 

Traffic B has three routes: one learned via IBGP network, one via static network, and 
one via local network. 

Rl-1: Configure connection to RPKI VC 1, enable Extended Community String. 

Rl-2: Configure connection to RPKI VC 2, enable Extended Community String. 

The following configuration for Routers AS65501 and AS65501i has been added: 



Test 4 5 1 
Config.txt 


IPv4 or IPv6? 

Both 

Test Harness or 

Hardware with Live RPKI 



Hardware with Live RPKI? 



Procedure 

1 . 

Configure the AS 65511 router to redistribute Traffic A to AS 65501. 

2. 

Configure AS 65501 to redistribute Traffic B. 


3. 

Rl-1: Verify that the router contains Traffic A and B. 


4. 

Rl-1: Verify that the router contains RVPs in the RPKI table. 


5. 

Rl-1: Verify tha the router validated Traffic A as invalid. 
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6 . Rl-1: Verify that the router validated Traffic B as either invalid or not found. 

1. Rl-1: Send Traffic A and B to Rl-2 with Extended Community String. 

8 . Rl-2: Verify that the router contains RVPs in the RPKI table. 

9. Rl-2: Verify the receipt of Traffic A and B and that a validation state of valid is 
assigned to all routes. 

For IPv6, use FD10:10:10:10::/64, FD20:20:20:l::/64, FD30:30:30:l::/64, 
FD40:40:40:l::/64. 

Expected 

Results 

Each of the expected results in Steps 3, 4, 5, 6, 8, and 9 above will be verified. 

Actual Results 

Vendor implementation varies. Certain vendors present all local routes and prefixes 
as vaiid, while others show them as unverified. 

Additional 

Comments 
(If Needed) 

Whereas RFC 6810 stipulates that routes or prefixes learned locallv (IGP, static, and 
connected) should be designated as not found, vendor implementation variable 
interprets them as either unverified or valid. 


2842 E.3.4.6 Test Case: SIDR-ROV-4.6.1 


Test Objective 

Examine RPKI validation by using eBGP, IGP, static, and local network routes within 


an iBGP network using two distinct VCs with conflicting records within the iBGP 
peers while enabling Extended Community String. Verify the validation state of the 

RUT. 

Preconditions 

The testbed is configured with the topology, IP addressing scheme, and ASNs as 
depicted in the Testbed Architecture in Figure E-2. 

AS 65511 is connected to AS 65501, and AS 65501 consists of two routers speaking 

iBGP. 

The edge router connected to AS 65511 is labeled Rl-1, and the IBGP peer to 
AS65501-R1-1 is labeled AS65501i-Rl-2. 

The RPKI VC 1 contains all used IP prefixes, but for origin 65509. The RPKI VC 2 
contains all used IP prefixes of Traffic A with origin 65511, and IP prefixes of Traffic B 
with origin 65501. 

VC 1 should result in invalid of all routes in Rl-1, and VC 2 will result in valid of all 
routes in Rl-2, if validated using the RPKI validation algorithm. 
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Expected Each of the expected results in Steps 3, 4, 5, 6, 8, and 9 above will be verified. 

Results 


Actual Results Vendor implementation varies. Certain vendors present all local routes and prefixes 
as valid, while others show them as unverified. 

Additional Whereas RFC 6810 stipulates that routes or prefixes learned locally (IGP, static, and 
Comments connected) should be designated as not found, vendor implementation variable 

(If Needed) interprets them as either unverified or valid. 
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2843 E.3.5 Applying Policies to ROV - Route Selection Process 

2844 E.3.5.1 Test Case: SIDR-ROV-5.1.1 


Test Objective 

RUT: If the route is invalid, discard the route; if the route is not found, install the 


route with a low LP value. 

Preconditions 

The testbed is configured with the topology, IP addressing scheme, and ASNs as 
depicted in the Testbed Architecture in Figure E-1 and Figure E-2. 

IPv4 or IPv6? 

Both Test Harness or Both 

Hardware with Live RPKI? 

Procedure 

1. Configure AS 65510 and AS65511 to send traffic to RUT AS65501. 

2. AS65510 and AS65511 send the following Prefixes: 

a. 10.10.0.0/16, AS65510 and AS65511 

b. 10.20.0.0/16, AS65510 and AS65511 

c. 10.30.0.0/16, AS65510 and AS65511 

d. 10.40.0.0/16, AS65511 (not found) 

e. 10.50.0.0/16, AS65510, but has ROV in AS65507 (invalid) 

3. Configure AS 65501 with a single policy to: 

a. Discard the prefix with invalid. 

b. Apply "Local Preference = 90" for the prefix with not found. 

c. Accept prefixes that are valid. 

4. Verify that the RUT contains appropriate policies. 

For IPv6, use FD10:10:10:0::/64, FD20:20:20::/64, FD30:30:30::/64, 

FD40:40:40::/64. 

Expected 

Results 

Invalid routes will be discarded. 

Not found routes will have an LP of 90. 

Valid routes will be inserted in the routing table with a default LP. 

Actual Results 

All implemented polices performed as expected. 

Additional 
Comments (If 
Needed) 

Note that one vendor (e.g., Cisco) discards invalid routes by default, while another 
vendor leaves the decision to discard to its customer. 
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2845 E.3.5.2 Test Case: SIDR-ROV-5.1.2 


Test 

Objective 


RUT: Allow the installation of invalid routes and configure policies such that: 
If the route is invalid, install the route with LP=70. 

If the route is not found, install the route with LP=80. 


If the route is valid, install the route with LP=110. 


Preconditions The testbed is configured with the topology, IP addressing scheme, and ASNs as 
depicted in the Testbed Architecture in Figure E-1 and Figure E-2 . 


IPv4 or IPv6? 

Both 

Test Harness or 

Both 



Hardware with Live RPKI? 



Configure AS 65510 and AS65511 to send traffic to RUT AS65501. 

AS65510 and AS65511 send the following Prefixes: 

a. 10.10.0.0/16, AS65510 and AS65511 

b. 10.20.0.0/16, AS65510 and AS65511 

c. 10.30.0.0/16, AS65510 and AS65511 

d. 10.40.0.0/16, AS65511 (notfound) 

e. 10.50.0.0/16, AS65510, but has ROV in AS65507 (invalid) 

Configure AS 65501 with a single policy to: 

a. If the route is invalid, install the route with LP=70. 

b. If the route is not found, install the route with LP=80. 

c. If the route is valid, install the route with LP=110. 

Verify that the RUT contains appropriate policies. 

For IPv6, use FD10:10:10:0::/64, FD20:20:20::/64, FD30:30:30::/64, FD40:40:40::/64. 


Procedure 


3. 


4. 


Expected 

Results 


Invalid routes with LP=70 
Not found routes with LP=80 


Valid routes with LP=110 


Actual All implemented policies performed as expected. 

Results 


Additional Note that one vendor (e.g., Cisco) discards invalid routes by default, while another 
Comments (If vendor leaves the decision to discard to its customer. 

Needed) 
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2846 E.3.6 Router Cache Synchronization 

2847 E.3.6.1 Test Case: SIDR-ROV-6.1.1 


Test Objective Test SIDR Requirements CR-3.1.1, CR-3.3.1, CR-3.5.1, CR-3.7.1, and CR-3.8.1 when 
working with IPv4/6 addresses. Show that the RUT receives and installs VRPs into 
RPKI database properly after a loss of connectivity to the RPKI validator. 


Preconditions The testbed is configured with the topology, IP addressing scheme, and ASNs as 
depicted in the Testbed Architecture in Figure E-1 and Figure E-2 . 

The rut's cache is empty, and the RPKI validator/cache is empty. The following 
configuration for the Cisco lOS XR router is used as the baseline for this test: 



Test 6 11 
Config.txt 


IPv4 or IPv6? 

Both 

Test Harness or 

Both 



Hardware with Live RPKI? 



Verify that the RUT has an empty RPKI database. 

From the RPKI cache, there are four ROAs: 

a. 10.100.0.0/16 16 65500 

b. 10.100.0.0/16 20 65500 

c. 10.100.0.0/16 24 65500 

d. FD00:10:100::/64 64 65500 

Configure the RUT with the VC by using the following file: 

S 

6-1-1 Cache 
Config.txt 

Verify that the RUT received and installs all VRPs in Step 2 into the database. 
Disconnect the RUT from the cache by disconnecting the Transmission Control 
Protocol (TCP) connection (i.e., via firewall). 

Remove the ROAs from Steps 2a and 2d from the RPKI validator. 

Add ROAs to the RPKI validator: 

a. 10.100.0.0/16 16 65510 

b. FD00:10:100::/64 64 65510 

Reenable the TCP connection between the RUT and the RPKI validator. 


Procedure 


4. 

5. 

6. 
7. 


8. 
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9. Verify that the RUT received and installed VRPs in the RPKI database and that it 
contains only VRPs in Steps 2b, 2c, and 7. 

Expected 

Results 

Each of the expected results in Steps 1, 3, and 8 above will be verified. 

Actual Results 

Test completed and functions as intended in Steps 1, 3, and 8. 

Additional 

Comments 
(If needed) 

The TCP connection was disrupted by shutting down the TCP interface. After 
reenabling the interface, a new TCP session was established. 


E.3.6.2 Test Case: SIDR-ROV-6.2.1 


Test Objective 


Test SIDR Requirements CR-3.1.1, CR-3.3.1, CR-3.5.1, CR-3.7.1, and CR-3.8.1 when 
working with IPv4/6 addresses. Show that the RUT and the RPKI validator function 
properly when the RPKI validator loses power, causing it to lose state. 
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3. Configure the RUT with the VC by using the following file: 

Test 6-2-1 Cache 

Config.txt 

4. Verify that the RUT received the cache and installed all VRPs in Step 2 into the 
database. 

5. Perform a hard reset of the RPKI validator (reboot the RPKI validator server). 

6 . Once the RPKI validator is restarted, it contains the following ROAs: 

a. 10.100.0.0/16 16 65510 

b. 10.100.0.0/16 20 65500 

c. 10.100.0.0/16 24 65500 

d. FD00:10:100::/64 64 65501 

7. Verify that the RUT received and installed VRPs in the RPKI database from 

Step 5. 

Expected 

Results 

Each of the expected results in Steps 1, 3, and 6 above will be verified. 

Actual Results 

Test completed and functions as intended in Steps 1, 3, and 6, but only if the VC 
presented a new session ID [RFC 68101 for the newlv created session. 

Additional 

Comments 

(If Needed) 

In cases where the cache presented the router erroneously with a re-used session 

ID, not all router implementations cleared the previous validation state correctly 
immediately. This problem was resolved, after a configurable time period of one 
minute up to one hour. 


2849 E.3.6.3 Test Case: SIDR-ROV-6.3.1 


Test 

Objective 

Test SIDR Requirements CR-3.1.1, CR-3.3.1, CR-3.5.1, CR-3.7.1, and CR-3.8.1 when 
working with IPv4/6 addresses. Show that the RUT receives and installs VRPs into 
the RPKI database properly after the RUT experienced a loss of power. 

Preconditions 

The testbed is configured with the topology, IP addressing scheme, and ASNs as 
depicted in the Testbed Architecture in Figure E-1 and Figure E-2. 

The rut's cache is empty, and the RPKI validator/cache is empty. The following 
configuration for the Cisco lOS XR router is used as the baseline for this test: 
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Test 6-3-1 
Config.txt 


IPv4 or IPv6? 

Both 

Test Harness or 

Both 



Hardware with Live RPKI? 



Verify that the RUT has an empty RPKI database. 

From the RPKI cache, receive four ROAs: 

a. 10.100.0.0/16 16 65500 

b. 10.100.0.0/16 20 65500 

c. 10.100.0.0/16 24 65500 

d. FD00:10:100::/64 64 65500 

Configure the RUT with the VC by using the following file: 

S 

Test 6-3-1 Cache 
Config.txt 

Verify that the RUT received and installed all VRPs in Step 2 into the database. 
Disconnect the RUT from the cache by going through a power cycle on the RUT. 
Remove the ROAs from the RPKI validator in Steps 2a and 2d. 

Add two ROAs: 

a. 10.100.0.0/16 16 65510 

b. FD00:10:100::/64 64 65510 

Reenable the TCP connection between the RUT and the RPKI validator. 

Verify that the RUT received and installed VRPs in the RPKI database and that the 
RUT contains only VRPs in Steps 2b, 2c, 7a, and 7b. 


Expected 

Results 

Each of the expected results in Steps 1, 3, and 8 above will be verified. 

Actual 

Results were as expected. 

Results 


Additional 

None 

Comments 


(If Needed) 



Procedure 

2 . 


3. 


4. 

5. 

6. 
7. 


8. 

9. 
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2850 E.3.6.4 Test Case: SIDR-ROV-6.4.1 


Test Objective Test SIDR Requirements CR-3.1.1, CR-3.3.1, CR-3.5.1, CR-3.7.1, and CR-3.8.1 when 
working with IPv4/6 addresses. Show that the RUT receives and installs VRPs into 
the RPKI database properly when switching to a cache with a different RPKI state. 


Preconditions The testbed is configured with the topology, IP addressing scheme, and ASNs as 
depicted in the Testbed Architecture in Figure E-1 and Figure E-2 . 

The rut's cache is empty, and RPKI validator/caches 1 and 2 are empty. The 
following configuration for the Cisco lOS XR router is used as the baseline for this 
test: 



Test 6^ 1 
Config.txt 


IPv4 or IPv6? 

Both 

Test Harness or 

Both 



Hardware with Live RPKI? 



Verify that the RUT has an empty RPKI database. 

Connect the RUT to RPKI Cache 1 and receive four ROAs: 

a. 10.100.0.0/16 16 65500 

b. 10.100.0.0/16 20 65500 

c. 10.100.0.0/16 24 65500 

d. FD00::10.100.0.0/64 64 65500 

Configure the RUT with the VC by using the following file: 

Test G'T-I Cache 
Config.txt 

Verify that the RUT received and installed all VRPs in Step 2 into the database. 
Disconnect the RUT from the cache by using RUT configuration commands to 
remove the cache from the RUT. 

Connect the RUT to RPKI Cache 2 and receive three ROAs: 

a. 10.100.0.0/16 16 65510 

b. 10.100.0.0/16 20 65500 

c. FD00::10.100.0.0/64 64 65510 

Verify that the RUT received all VRPs in the RPKI database coming from Cache 2 
and that no VRP is left from Cache 1. 

Only the VRPs of Steps 6a, 6b, and 6c must reside in the RUT's RPKI database. 


Procedure 

2 . 

3. 

4. 

5. 

6. 

7. 
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Expected 

Results 

Each of the expected results in Steps 1, 3, and 6 above will be verified. 

Actual Results 

Results were as expected. 

Additional 

Comments 
(If Needed) 

This experiment included operator involvement. In our test cases, we did not 
encounter any issues with remaining stale data, but, even if we had, clearing the 
table would resolve the issue. 


Also, all vendor systems that we used perform a union on the validation databases. 
Therefore, it will be good practice to add the new cache and retrieve the VRP data 
prior to removing the old cache, to keep churn in the routing table to a minimum. 


2851 E.3.6.5 Test Case: SIDR-ROV-6.5.1 


Test Objective Test SIDR Requirements CR-3.1.1, CR-3.3.1, CR-3.5.1, CR-3.7.1, and CR-3.8.1 when 
working with IPv4/6 addresses. Show that the RUT receives and installs VRPs of 
two identical RPKI caches into the RPKI database properly. Then Cache 1 
disappears. 


Preconditions The testbed is configured with the topology, IP addressing scheme, and ASNs as 
depicted in the Testbed Architecture in Figure E-1 and Figure E-2 . 

The rut's cache is empty, and RPKI validator/caches 1 and 2 are empty. The 
following configuration for the Cisco lOS XR router is used as the baseline for this 
test: 



Test 6 5 1 
Config.txt 


IPv4 or IPv6? 

Both 

Test Harness or 

Both 



Hardware with Live RPKI? 



Verify that the RUT has an empty RPKI database. 

Connect the RUT to RPKI Cache 1 and receive three ROAs: 

a. 10.100.0.0/16 16 65510 

b. 10.100.0.0/16 20 65510 

c. FD00::10.100.0.0/64 64 65510 

Connect the RUT to RPKI Cache 2 and receive three ROAs: 


Procedure 


3. 
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a. 10.100.0.0/16 16 65510 

b. 10.100.0.0/16 20 65510 

c. FD00::10.100.0.0/64 64 65510 

4. Configure the RUT with the VCs by using the following file: 

S 

Test 6-5-1 Cache 

Config.txt 

5. Verify that the RUT received all VRPs in the RPKI database coming from Caches 1 
and 2. 

6. The RUT receives Update 10.100.0.0/16 65510. 

7. Verify that the RUT received the update from Step 6 and validated it as valid. 

8. The RUT receives Update 10.100.0.0/16 65511. 

9. Verify that the RUT received the update from Step 8 and validated it as invalid. 

10. Shut down Cache 1. 

11. Verify that the validation state of both updates did not change. 

Expected 

Results 

Each of the expected results in Steps 1, 4, 6, 8, and 10 above will be verified. 

Actual Results 

Performed as expected. 

Additional 

Comments 
(If needed) 

The vendor implementations act differently, mainly controlled by configuration. This 
means that one implementation identified the loss of the cache faster than the 
other. We identified, though, that the router that kept data longer cleared stale data 
after a configured time span between one minute and one hour. 


2852 E.3.6.6 Test Case: SIDR-ROV-6.6.1 


Test Objective 

Test SIDR Requirements CR-3.1.1, CR-3.3.1, CR-3.5.1, CR-3.7.1, and CR-3.8.1 when 
working with IPv4/6 addresses. Show that the RUT receives and installs VRPs of 
two RPKI caches with a slightly different view on the RPKI into the RPKI database 
properly. Then Cache 1 disappears. 

Preconditions 

The testbed is configured with the topology, IP addressing scheme, and ASNs as 
depicted in the Testbed Architecture in Figure E-1 and Figure E-2. 

The rut's cache is empty, and RPKI validator/caches 1 and 2 are empty. 
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IPv4 or IPv6? 

Both Test Harness or Both 

Hardware with Live RPKI? 

Procedure 

1. Verify that the RUT has an empty RPKI database. 

2. Connect the RUT to RPKI Cache 1 and receive three ROAs: 

a. 10.100.0.0/16 16 65510 

b. 10.100.0.0/16 20 65510 

c. FD00::10.100.0.0/64 64 65510 

3. Connect the RUT to RPKI Cache 2 and receive three ROAs: 

a. 10.100.0.0/16 16 65511 

b. 10.100.0.0/16 20 65511 

c. FD00::10.100.0.0/64 64 65511 

4. Configure the RUT with the VCs by using the following file: 

Test 6-6-1 Cache 

Config.txt 

5. Verify that the RUT received all VRPs in the RPKI database coming from 

Caches 1 and 2. 

6. The RUT receives Update 10.100.0.0/16 65510. 

7. Verify that the RUT received the update from Step 6 and validated it as valid. 

8. The RUT receives Update 10.100.0.0/16 65511. 

9. Verify that the RUT received the update from Step 8 and validated it as valid or 
invalid, depending on if both caches are active or only Cache 1. 

10. The RUT receives Update 10.100.0.0/15 65510. 

11. Verify that the RUT validates the received update from Step 10 as not found. 

12. Shut down Cache 1. 

13. Verify that the RUT contains only VRP values of 3. 

14. Verify that Update 6 is invalid, 8 is valid, and 10 is not found. 

Expected 

Results 

Each of the expected results in Steps 1, 4, 6, 8, 10,12, and 13 above will be verified. 

Actual Results 

As expected 

Additional 

Comments 
(If Needed) 

The vendor implementations act differently, mainly controlled by configuration. 

This means that one implementation identified the loss of the cache faster than the 
other. We identified, though, that the router that kept data longer cleared stale 
data after a configured time span between one minute and one hour. 

Also, all router implementations tested take a union of the connected caches. 
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2853 E.3.7 SIDR Delegated Model Test Cases 

2854 Test case SIDR-ROV-2.7.2 is identical to test case SIDR-ROV-2.7.1, except that IPv6 addresses are used 

2855 instead of IPv4 addresses. 

2856 The following tests are designed to verify capabilities related to the implementation of a delegated CA. 

2857 E.3.7.1 Test Case: SIDR-DM-7.1.1 

Test Objective Test SIDR Requirements CR-3.1.1, CR-3.3.1, CR-3.5.1, CR-3.7.1, and CR-3.8.1 when 
working with IPv4 addresses. Show that a resource holder can set up its own CA as 
a delegated RPKI participant and create, store, and manage ROAs for its own 
addresses in its own repository, and that this ROA information will be downloaded 
to local VCs and provided to routers that are performing ROV. Further show that 
ROAs will be removed from the RPKI upon expiration. 

(This test is analogous to test SIDR-DM-3.2.1. In this test, a resource holder sets up 
its own delegated CA and repository and demonstrates the ability to create, 
manage, and store ROAs for itself. The SIDR-DM-3.2.1 test is the same, except that, 
in SIDR-DM-3.2.1, the resource holder demonstrates the ability to create, manage, 
and store ROAs for its customers.) 
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2. Use the show ip bgp rpki table command at the RUT to list the VRP information 
that it has received from its VC. Verify that the RUT has not received any VRPs 
that cover the addresses listed in the previous step. 

3. AS 65501 sets up a CA and a repository within its own AS as a child of the test 
RIR. 

4. AS 65501 creates three ROAs: 

a. (10.10.128.128/19, 19, AS 65501) 

b. (10.10.128.192/19, 19, AS 65501) 

c. (10.10.128.224/19, 19, AS 65501) 

The first two ROAs are created with default expiration time values (i.e., their 
end-entity [EE] certificates have the default expiration value, which, in the case 
of the tool we are using, is one year from creation). The third ROA's 
corresponding EE certificate is given an expiration time of 24 hours from 
creation. 

5. Verify, by looking in AS 6550rs repository, that these three ROAs have been 
created and are stored in the repository. 

6. Wait for an amount of time to elapse that is greater than the RPKI-to-VC content 
update interval, but less than 12 hours (i.e., within the expiration time set for 
the third ROA created in Step 4 above). (Or, alternatively, force the VC to be 
updated with the latest RPKI repository information.) 

7. Verify that all three of the ROAs that were created in Step 4 above have been 
received by the VC that is attached to the RUT. 

8. Wait for an amount of time to elapse that is greater than the VC-to-router 
refresh interval but less than 12 hours (i.e., still within the expiration time set for 
the third ROA created in Step 4 above). 

9. Verify that VRPs for all three of these ROAs have been received by the RUT that 
is attached to this VC. (Use the show ip bgp rpki table command at the RUT to 
list the VRP information that it has received from its VC.) 

10. Wait for an amount of time to elapse so that the 24-hour expiration time set in 
Step 4 above will have passed. 

11. Verify by looking in AS 6550rs repository that only the first two ROAs that were 
created in Step 4 remain in the repository, i.e., the third ROA is no longer in the 
repository, i.e., 

a. (10.10.128.128/19, 19, AS 65501) is present 

b. (10.10.128.192/19, 19, AS 65501) is present 

c. (10.10.128.224/19, 19, AS 65501) is absent 

12. Wait for an amount of time to elapse that is greater than the RPKI-to-VC content 
update interval or, alternatively, force the validator/validating cache to be 
updated with the latest RPKI repository information. 
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13. Verify that VRPs for only the first two ROAs created in Step 4 above have been 
received by the VC that is attached to the RUT. 

14. Wait for an amount of time to elapse that is greater than the VC-to-router 
refresh interval. 

15. Verify that VRPs for only the first two ROAs created in Step 4 are received by the 
RUT (i.e., no VRP for the third ROA is received by the router). (Use the show ip 
bgp rpki table command at the RUT to list the VRP information that it has 
received from its VC.) 

16. Remove ROA 10.10.128.192/19 AS 65501. 

17. Verify, by looking in AS 6550rs repository, that only the first ROA that was 
created in Step 4 remains in the repository (i.e., that the second and third ROAs 
are no longer in the repository): 

a. (10.10.128.128/19, 19, AS 65501) is present. 

b. (10.10.128.192/19, 19, AS 65501) is absent. 

c. (10.10.128.224/19, 19, AS 65501) is absent. 

18. Wait for an amount of time to elapse that is greater than the RPKI-to-VC content 
update interval, or, alternatively, force the validator/validating cache to be 
updated with the latest RPKI repository information. 

19. Verify that a VRP for only the first ROA created in Step 4 above has been 
received by the VC that is attached to the RUT. 

20. Wait for an amount of time to elapse that is greater than the VC-to-router 
refresh interval. 

21. Verify that a VRP for only the first ROA created in Step 4 is received by the RUT 
(i.e., no VRP for the second or third ROA is received by the router). (Use the 
show ip bgp rpki table command at the RUT to list the VRP information that it 
has received from its VC.) 

Expected 

Results 

Each of the expected results in Steps 5, 7, 9, 11, 13, 15, 17, 19, and 21 will be 
verified. 

Actual Results 

Unable to complete certain steps. See comments below. 

Additional 
Comments (If 
Needed) 

Observations (with comments) 

Steps 6 through 10 cannot be met because the Dragon Research Labs RPKI.net 
toolkit does not permit specifying an expiration date of an EE certificate. According 
to the creators of the only documented delegated RPKI toolkit, the toolkit was 
designed under the assumption that all ROAs in the repository should have current 

EE certificates. If their EE certificate is expired, it shouldn't be in the repository. 

There is debate as to whether this is a sound model. For example, the American 
Registry for Internet Numbers' (ARIN's) hosted RPKI model permits the specification 
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of EE certificate expiration dates. All test procedures are possible, with the exception 
of the specification of an EE certificate expiration date. 


2858 Test case SIDR-DM-3.1.2 is identical to test case SIDR-DM-3.1.1, except that IPv6 addresses are used 

2859 instead of IPv4 addresses. 

2860 E.3.7.2 Test Case: SIDR-DM-7.2.1 


Test Objective Test SIDR Requirements CR-3.2.1, CR-3.4.1, CR-3.6.1, CR-3.7.1, and CR-3.8.1 when 
working with IPv4 addresses. Show that a resource holder can set up its own CA as 
a delegated RPKI participant and create, store, and manage ROAs on behalf of its 
customers in its own repository, and that this ROA information will be 
downloaded to local VCs and provided to routers that are performing ROV. Further 
show that these ROAs will be removed from the RPKI upon expiration. 

(This test is analogous to test SIDR-DM-3.1.1. In this test, a resource holder sets up 
its own delegated CA and repository and demonstrates the ability to create, 
manage, and store ROAs on behalf of its customers. The SIDR-DM-3.1.1 test is the 
same, except that, in SIDR-DM-3.1.1, the resource holder demonstrates the ability 
to create, manage, and store ROAs for itself.) 



NIST SP 1800-14B: Protecting the Integrity of Internet Routing 


164 













DRAFT 


2. Use the show ip bgp rpki table command at the RUT to list the VRP information 
that it has received from its VC. Verify that the RUT has not received any VRPs 
that cover the addresses listed in the previous step. 

3. AS 65501 sets up a CA and a repository within its own AS as a child of the test 
RIR. 

4. AS 65501 creates three ROAs for portions of its own address space that it is 
delegating to AS 65505, thereby authorizing AS 65505 to originate BGP updates 
for these addresses: 

a. (10.10.240.128/20, 20, AS 65505) 

b. (10.10.240.192/19, 19, AS 65505) 

c. (10.10.240.224/19, 19, AS 65505) 

The first two ROAs are created with default expiration time values (i.e., their EE 
certificates have the default expiration value, which, in the case of the tool that 
we are using, is one year from creation). The third ROA's corresponding EE 
certificate is given an expiration time so that it will expire 24 hours from 
creation. 

5. Verify, by looking in AS 6550rs repository, that these three ROAs have been 
created and are stored in the repository. 

6. Wait for an amount of time to elapse that is greater than the RPKI-to-VC content 
update interval, but less than 12 hours (i.e., prior to the expiration time set for 
the third ROA created in Step 4 above). (Or, alternatively, force the VC to be 
updated with the latest RPKI repository information.) 

7. Verify that all three of the ROAs that were created in Step 4 above have been 
received by the VC that is attached to the RUT. 

8. Wait for an amount of time to elapse that is greater than the VC-to-router 
refresh interval, but less than 12 hours (i.e., still prior to the expiration time set 
for the third ROA created in Step 4 above). 

9. Verify that VRPs for all three of these ROAs have been received by the RUT that 
is attached to this VC. (Use the show ip bgp rpki table command at the RUT to 
list the VRP information that it has received from its VC.) 

10. Wait for an amount of time to elapse so that the 24-hour expiration time set in 
Step 4 above will have passed. 

11. Verify, by looking in AS 6550rs repository, that only the first two ROAs that 
were created in Step 4 remain in the repository (i.e., the third ROA is no longer 
in the repository): 

a. (10.10.240.128/19, 19, AS 65501) is present. 

b. (10.10.240.192/19, 19, AS 65501) is present. 

c. (10.10.240.224/19, 19, AS 65501) is absent. 
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12. Wait for an amount of time to elapse that is greater than the RPKI-to-VC content 
update interval, or, alternatively, force the validator/validating cache to be 
updated with the latest RPKI repository information. 

13. Verify that VRPs for only the first two ROAs created in Step 4 above have been 
received by the VC that is attached to the RUT. 

14. Wait for an amount of time to elapse that is greater than the VC-to-router 
refresh interval. 

15. Verify that VRPs for only the first two ROAs created in Step 4 are received by the 
RUT (i.e., no VRP for the third ROA is received by the router). (Use the show ip 
bgp rpki table command at the RUT to list the VRP information that it has 
received from its VC.) 

16. AS 65501 revokes the second ROA that was created in Step 4 above. 

17. Verify, by looking in AS 6550rs repository, that only the first ROA that was 
created in Step 4 remains in the repository (i.e., that the second and third ROAs 
are no longer in the repository): 

a. (10.10.240.128/19, 19, AS 65501) is present. 

b. (10.10.240.192/19, 19, AS 65501) is absent. 

c. (10.10.240.224/19, 19, AS 65501) is absent. 

18. Wait for an amount of time to elapse that is greater than the RPKI-to-VC content 
update interval, or, alternatively, force the validator/validating cache to be 
updated with the latest RPKI repository information. 

19. Verify that a VRP for only the first ROA created in Step 4 above has been 
received by the VC that is attached to the RUT. 

20. Wait for an amount of time to elapse that is greater than the VC-to-router 
refresh interval. 

21. Verify that a VRP for only the first ROA created in Step 4 is received by the RUT, 
(i.e., no VRP for the second or third ROA is received by the router). (Use the 
show ip bgp rpki table command at the RUT to list the VRP information that it 
has received from its VC.) 

Expected 

Results 

Each of the expected results in Steps 4, 6, 8, 10, 12, and 14 will be verified. 

Actual Results 

Unable to complete certain steps. See comments below. 

Additional 
Comments (If 
Needed) 

Observations (with comments) 

Similar to above. Steps 6 through 10 cannot be met because the Dragon Research 

Labs RPKI.net toolkit does not permit specifying an expiration date of an EE 
certificate. According to the creators of the only documented delegated RPKI toolkit, 
the toolkit was designed under the assumption that all ROAs in the repository 
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should have current EE certificates. If their EE certificate is expired, it shouldn't be in 
the repository. There is debate as to whether this is a sound model. For example, 
ARIN's hosted RPKI model permits the specification of EE certificate expiration dates. 
All test procedures are possible, with the exception of the specification of an EE 
certificate expiration date. 
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Appendix F 

Acronyms 

ANTD 

Advanced Network Technology Division 

ARIN 

American Registry for Internet Numbers 

AS 

Autonomous System 

ASN 

Autonomous System Number 

BGP 

Border Gateway Protocol 

BGP-4 

Border Gateway Protocol 4 

BGPsec 

Border Gateway Protocol Security 

BIO 

BGPSEC-IO 

CA 

Certificate Authority 

COI 

Community of Interest 

COTS 

Commercial Off-The-Shelf 

CRADA 

Cooperative Research and Development Agreement 

CVE 

Common Vulnerability Exposures 

DE 

Detect 

DoS 

Denial of Service 

eBGP 

Exterior Border Gateway Protocol 

EE 

End-Entity 

FIB 

Forwarding Information Base 

FIPS 

Federal Information Processing Standards 

FRN 

Federal Register Notice 

GbE 

Gigabit(s) Ethernet 

Gbps 

Gigabit(s) per Second (Billions of Bits per Second) 

iBGP 

Interior Border Gateway Protocol 

ID 

Identity 

lEC 

International Electrotechnical Commission 
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IEEE 

Institute of Electrical and Electronics Engineers 

IETF 

Internet Engineering Task Force 

IGP 

Interior Gateway Protocol 

INR 

Internet Number Resource 

IP 

Internet Protocol 

ISO 

International Organization for Standardization 

ISP 

Internet Service Provider 

IT 

Information Technology 

ITL 

Information Technology Lab 

LOI 

Letters of Interest 

LP 

Local Preference 

MaxLength 

Maximum Prefix Length 

NANOG 

North American Network Operators Group 

NCCoE 

National Cybersecurity Center of Excellence 

NCEP 

National Cybersecurity Excellence Partnership 

NDI 

Non-Developmental Items 

NIST 

National Institute of Standards and Technology 

OS 

Operating System 

PANW 

Palo Alto Next-Generation Firewall 

PKI 

Public Key Infrastructure 

PR 

Protect 

RFC 

Request for Comments 

RIPE NCC 

Reseaux IP Europeens Network Coordination Centre 

RIR 

Regional Internet Registry 

RMF 

Risk Management Framework 

ROA 

Route Origin Authorization 
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ROM 

Rough Order of Magnitude 

ROV 

Route Origin Vaiidation 

RP 

Reiying Party 

RPKI 

Resource Pubiic Key infrastructure 

RPM 

RPM Package Manager 

RRDP 

RPKi Repository Deita Protocoi 

RS 

Respond 

RSA 

Registration Services Agreement 

rsync 

Remote Synchronization 

RUT 

Router Under Test 

SIDR 

Secure inter-Domain Routing 

SLURM 

Simpiified Locai internet Number Resource Management 

SONET 

Synchronous Opticai Network 

SP 

Speciai Pubiication 

SQL 

Structured Query Language 

TAL 

Trust Anchor Locator 

TCP 

Transmission Controi Protocoi 

TPO 

Technoiogy Partnerships Office 

U.S. 

United States 

UDP 

User Datagram Protocoi 

URI 

Uniform Resource identifier 

VC 

Vaiidating Cache 

VM 

Virtuai Machine 

VRP 

Vaiidated ROA Payioad 
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^ "Failed" ROV indicates that the ROV evaluation process determines the route to be invalid. 

^ IPv4 or IPv6 address space and AS Numbers (ASNs). ASNs are two- or four-byte numbers issued by a 
registry to identify an AS in BGP. 

^ The attacks listed assume that an adversary does not have access to the cryptographic keys needed to 
generate valid RPKI-signed products. 

^ System Query Language. 

^ https://www.cisco.com/c/en/us/products/collateral/routers/7200-series- 

routers/data sheet c78 339749.html . 

^ https://www.iuniper.net/us/en/products-services/routing/mx-series/mx80/ . 

^ BGPSECIO User Manual, which can be found at [NIST BGP-SRx] . 

® The term "risk treatment" as defined in [ISO 73] is used in [ISO/IEC/IEEE 15288]. 

® Collaborator function. 

“ Collaborator function. 

For laboratory set-up - excludes collaborator and NCEP contributions. 

Focus is on protection of government property and of collaborator intellectual property and 
components. 

Focus is on protection of government property and of collaborator intellectual property and 
components 

Here, AQ-2 is applied to the process employed to advertise for and acquire collaborators. Build 
components are provided by the collaborators. 

The focus of AR-3 was on CRADAs for this project. NIST's Technology Partnerships Organization had 
the lead for CRADAs. 
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SP-2 and SP-3 are collaborator functions. 

Verified that collaborator contributions met security requirements as stated in the FRN and Project 
Description. 

Looked at functional interdependencies among NCCoE internet security projects. 

Conducted as part of the Practice Guide Volume B development. 

“ Conducted as part of the Practice Guide Volume B development. 

Conducted as part of the Practice Guide Volume B development. 

This task set focuses primarily on CRADAs with collaborators. 

SP-4 and SP-5 are primarily collaborator functions. 
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NATIONAL CYBERSECURITY CENTER OF EXCELLENCE 


The National Cybersecurity Center of Excellence (NCCoE), a part of the National Institute of Standards 
and Technology (NIST), is a collaborative hub where industry organizations, government agencies, and 
academic institutions work together to address businesses' most pressing cybersecurity issues. This 
public-private partnership enables the creation of practical cybersecurity solutions for specific 
industries, as well as for broad, cross-sector technology challenges. Through consortia under 
Cooperative Research and Development Agreements (CRADAs), including technology partners—from 
Fortune 50 market leaders to smaller companies specializing in IT security—the NCCoE applies standards 
and best practices to develop modular, easily adaptable example cybersecurity solutions using 
commercially available technology. The NCCoE documents these example solutions in the NIST Special 
Publication 1800 series, which maps capabilities to the NIST Cybersecurity Framework and details the 
steps needed for another entity to recreate the example solution. The NCCoE was established in 2012 by 
NIST in partnership with the State of Maryland and Montgomery County, Md. 

To learn more about the NCCoE, visit https://www.nccoe.nist.gov/ . To learn more about NIST, visit 
https://www.nist.gov . 

NIST CYBERSECURITY PRACTICE GUIDES 

NIST Cybersecurity Practice Guides (Special Publication Series 1800) target specific cybersecurity 
challenges in the public and private sectors. They are practical, user-friendly guides that facilitate the 
adoption of standards-based approaches to cybersecurity. They show members of the information 
security community how to implement example solutions that help them align more easily with relevant 
standards and best practices, and provide users with the materials lists, configuration files, and other 
information they need to implement a similar approach. 

The documents in this series describe example implementations of cybersecurity practices that 
businesses and other organizations may voluntarily adopt. These documents do not describe regulations 
or mandatory practices, nor do they carry statutory authority. 

ABSTRACT 

The Border Gateway Protocol (BGP) is the default routing protocol to route traffic among internet 
domains. While BGP performs adequately in identifying viable paths that reflect local routing policies 
and preferences to destinations, the lack of built-in security allows the protocol to be exploited by route 
hijacking. Route hijacking occurs when an entity accidentally or maliciously alters an intended route. 

Such attacks can (1) deny access to internet services, (2) detour internet traffic to permit eavesdropping 
and to facilitate on-path attacks on end points (sites), (3) misdeliver internet network traffic to malicious 
end points, (4) undermine internet protocol (IP) address-based reputation and filtering systems, and 
(5) cause routing instability in the internet. This document describes a security platform that 
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demonstrates how to improve the security of inter-domain routing traffic exchange. The platform 
provides route origin validation (ROV) by using the Resource Public Key Infrastructure (RPKI) in a manner 
that mitigates some misconfigurations and malicious attacks associated with route hijacking. The 
example solutions and architectures presented here are based upon standards-based, open-source, and 
commercially available products. 
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AS, autonomous systems, BGP, Border Gateway Protocol, DDoS, denial-of-service (DoS) attacks, internet 
service provider, ISP, Regional Internet Registry, Resource Public Key Infrastructure, RIR, ROA, route 
hijack, route origin authorization, route origin validation, routing domain, ROV, RPKI 
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Technology Partner/Collaborator Build Involvement 


AT&T 

Subject Matter Expertise 

CenturvLink 

1 gigabit per second (Gbps) Ethernet Link 

Subject Matter Expertise 

Cisco 

7206 VXR Router vl5.2 

ISR4331 Router V16.3 

2921 Router vl5.2 

lOSXRv 9000 Router V6.4.1 

Subject Matter Expertise 

Comcast 

Subject Matter Expertise 
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Palo Alto Networks 
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Subject Matter Expertise 

The George Washington University 
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38 1 Introduction 

39 The following guides show information technology (IT) professionals and security engineers how we 

40 implemented the example Secure Inter-Domain Routing (SIDR) Project solution for Resource Public Key 

41 Infrastructure (RPKI)-based route origin validation (ROV). We cover all of the products employed in this 

42 reference design. We do not recreate the product manufacturers' documentation, which is presumed to 

43 be widely available. Rather, these guides show how we incorporated the products together in our 

44 environment. 

45 Note: These are not comprehensive tutorials. There are many possible service and security 

46 configurations for these products that are out of scope for this reference design. 


47 1.1 Practice Guide Structure 

48 This National Institute of Standards and Technology (NIST) Cybersecurity Practice Guide demonstrates a 

49 standards-based reference design and provides users with the information they need to replicate the 

50 SIDR RPKI-based ROV solution. This reference design is modular and can be deployed in whole or in 

51 parts. 

52 NIST Special Publication (SP) 1800-14 contains three volumes: 


53 

54 

55 

56 

57 

58 

59 

60 
61 
62 


■ NIST SP 1800-14A: Executive Summary 

■ NIST SP 1800-14B: Approach, Architecture, and Security Characteristics - what we built and why 

■ NIST SP 1800-14C: How-To Guides - instructions for building the example solution (you are 
here) 

Depending on your role in your organization, you might use this guide in different ways: 

Business decision makers, including chief security and technology officers, will be interested in the 
Executive Summary (NIST SP 1800-14A), which describes: 

■ The challenges that enterprises face in implementing and maintaining route origin validation 

■ An example solution built at the National Cybersecurity Center of Excellence (NCCoE) 

■ Benefits of adopting the example solution 
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Technology or security program managers who are concerned with how to identify, understand, assess, 
and mitigate risk will be interested in NIST SP 1800-14B, which describes what we did and why. The 
following sections will be of particular interest: 

■ Section 4.4.3, Risks, provides a description of the risk analysis we performed 

■ Section 4.4.4, Cybersecurity Framework Functions, Categories, and Subcategories Addressed by 
the Secure Inter-Domain Routing Project, maps the security characteristics of this example 
solution to cybersecurity standards and best practices 

If you are a technology or security program manager, you might share the Executive Summary, NIST SP 
1800-14A, with your leadership team members to help them understand the importance of adopting 
the standards-based SIDR RPKI-based ROV solution. 

IT professionals who want to implement an approach like this can use the Flow-To portion of the guide, 
NIST SP 1800-14C, to replicate all or parts of the build created in our lab. The Flow-To guide provides 
specific product installation, configuration, and integration instructions for implementing the example 
solution. We do not recreate the product manufacturers' documentation, which is generally widely 
available. Rather, we show how we incorporated the products together in our environment to create an 
example solution. 

This guide assumes that IT professionals have experience implementing security products within the 
enterprise. While we have used a suite of commercial products to address this challenge, it is not NIST 
policy to endorse any particular products. Your organization can adopt this solution or one that adheres 
to these guidelines in whole, or you can use this guide as a starting point for tailoring and implementing 
parts of an RPKI-based ROV solution. Your organization's security experts should identify the products 
that will best integrate with your existing tools and IT system infrastructure. We hope that you will seek 
products that are congruent with applicable standards and best practices. Section 4.5, Technologies, of 
NIST SP 1800-14B lists the products that we used and maps them to the cybersecurity controls provided 
by this reference solution. 

A NIST Cybersecurity Practice Guide does not describe "the" solution, but a possible solution. This is a 
draft guide. We seek feedback on its contents and welcome your input. Comments, suggestions, and 
success stories will improve subsequent versions of this guide. Please contribute your thoughts to sidr- 
nccoe@nist.gov . 

1.2 Build Overview 

This NIST Cybersecurity Practice Guide addresses the challenge of using existing protocols to improve 
the security of inter-domain routing traffic exchange in a manner that mitigates accidental and malicious 
attacks associated with route hijacking. It implements and follows various Internet Engineering Task 
Force (IETF) Request for Comments (RFC) documents that define RPKI-based Border Gateway Protocol 
(BGP) ROV, such as RFC 6480, RFC 6482, RFC 6811, and RFC 7115, as well as recommendations of NIST 
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SP 800-54, Border Gateway Protocol Security. To the extent practicable from a system composition point 
of view, the security platform design, build, and test processes have followed NIST SP 800-160, Systems 
Security Engineering: Considerations for a Multidisciplinary Approach in the Engineering of Trustworthy 
Secure Systems. 

The ROV capabilities demonstrated by the proof-of-concept implementation described in this Practice 
Guide improve inter-domain routing security by using standards-conformant security protocols to 
enable an entity that receives a route advertisement to validate whether the autonomous system (AS) 
that has originated it is in fact authorized to do so. 

In the NCCoE lab, the team built an environment that resembles portions of the internet. The SIDR lab 
architecture is depicted in Figure 1-1 and Figure 1-2 . It consists of virtual and physical hardware, physical 
links to ISPs, and access to the Regional Internet Registries (RIRs). The physical hardware mainly consists 
of the routers performing ROV, workstations providing validator capabilities, and firewalls that protect 
the lab infrastructure. The virtual environment hosts the RPKI repositories, validators, and caches used 
for both the hosted and delegated RPKI scenarios. The architecture is organized into separate virtual 
local area networks (VLANs), each of which is designed to represent a different AS. For example, VLAN 1 
represents an ISP with AS 64501, VLAN 2 represents the enterprise network of an organization with AS 
64502, and VLAN 3 represents an ISP with AS 64503. 

The configurations in this document provide a baseline for completing all the test cases that were 
performed for the project. 

There are two environments that are used: test harness and live data. 

■ The test harness environment consists of physical/virtual routers, a lab RPKI repository, RPKI 
validators, and simulation tools (or test harness). The physical and virtual routers in this 
environment are from Cisco and Juniper. The lab RPKI repository is configured using the 
RPKI.net tool. The RPKI caches in this environment are the Reseaux IP Europeens Network 
Coordination Centre (RIPE NCC) validator and the RPKI.net validator. The test harness simulates 
BGP routers sending and receiving advertisements and emulates RPKI data being sent from 
validators/caches. There are two components of the test harness: the BGPSEC-IO (BIO) traffic 
generator and collector, which produces BGP routing data, and the SRx-RPKI validator cache test 
harness, which simulates RPKI caches. 

■ The live data environment leverages many of the same components from the test harness 
environment. The difference is that this environment leverages live data from the internet, 
rather than uses emulated BGP advertisements and RPKI data. The physical and virtual routers 
in this environment are from Cisco and Juniper. The lab RPKI repository is configured using the 
RPKI.net tool. Repositories from the RIRs (American Registry for Internet Numbers [ARIN], RIPE 
NCC, African Network Information Center [AFRINIC], Latin America and Caribbean Network 
Information Center [LACNIC], and Asia-Pacific Network Information Center [APNIC]) are also 
used to receive real-world route origin authorization (ROA) data. The RPKI caches in this 
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135 environment are the RIPE NCC validator and the RPKI.net validator. A physical wide area 

136 network (WAN) link is used to connect to CenturyLink to receive a full BGP table and to connect 

137 totheRIRs. 

138 Figure 1-1 Test Harness Environment for SIDR RPKI-Based ROV Solution Testing 
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BGPSEC-IO(BIO)- BGP traffic generator & collector / RTR - CISCO or Juniper Router 
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140 Figure 1-2 Live Data Environment for SIDR RPKI-Based ROV Solution Testing 
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142 1.3 Typographic Conventions 

143 The following table presents typographic conventions used in this volume. 


Typeface/Symbol 

Meaning 

Example 

Italics 

filenames and pathnames 

references to documents 
that are not hyperlinks, new 
terms, and placeholders 

For detailed definitions of terms, see 
the CSRC.NIST.GOVGlossary. 

Bold 

names of menus, options, 
command buttons, and 
fields 

Choose File > Edit. 

Monospace 

command-line input, on¬ 
screen computer output, 
sample code examples, 
status codes 

Mkdir 

Monospace Bold 

command-line user input 
contrasted with computer 
output 

service sshd start 

blue text 

link to other parts of the 
document, a web URL, or an 
email address 

All publications from NIST's National 
Cybersecurity Center of Excellence 
are available at 
http://www.nccoe.nist.gov 


144 2 Product Installation Guides 

145 This section of the Practice Guide contains detailed instructions for installing and configuring all of the 

146 products used to build an instance of the SIDR RPKI-based ROV example solution. The main components 

147 of the lab build consist of ROV-enabled routers, RPKI repositories, RPKI validators / validating caches 

148 (VCs), a live internet circuit, and firewalls. 
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149 2.1 RPKI Validators 

150 The RPKI validator receives and validates ROAs from the RPKI repositories of the trust anchors and 

151 delegated repositories. Currently, there are five trust anchors, all of which are managed by the RIRs: 

152 AFRINIC, APNIC, ARIN, LACNIC, and the RIPE NCC. A subset of the data from ROAs, called validated ROA 

153 payload (VRP), is then retrieved from the local RPKI validator by an RPKI-capable router to perform ROV 

154 of BGP routes. 

155 In this lab build, two RPKI validators (also referred to as VCs) are tested: the RIPE NCC RPKI validator and 

156 the Dragon Research RPKI.net validator. 


157 

158 

159 

160 

161 

162 

163 

164 

165 

166 

167 

168 

169 

170 

171 

172 

173 

174 

175 

176 

177 


2.1.1 RIPE NCC RPKI Validator Configuration/lnstallation 

The RIPE NCC RPKI validator is developed and maintained by RIPE NCC [RIPE Tools] . This validator tool is 
free and open-source. The version used in the build is 2.24. It is available for download at 
https://www.ripe.net/manage-ips-and-asns/resource-management/certification/tools-and-resources . 

System requirements: a UNIX-like operating system (OS), Java 7 or 8, rsync, and 2 gigabytes (GB) of free 
memory. 

Lab setup: CentOS 7 minimal install, Java 8, rsync, one central processing unit (CPU), 6 GB memory, and 
running on a virtual machine (VM) on VMware ESXi. 

For release notes, installation information, and source code, please view https://github.com/RIPE- 
NCC/rpki-validator/blob/master/rpki-validator-app/README.txt . 

1. Use the CentOS template to create the VM with the system requirements provided above. 

a. Put the VM in the proper VLAN. 

2. Install Java (must be Oracle 8) and open firewall to allow rsync. 

3. In the VM, create a folder under home called "RPKI". 

a. # mkdir RPKI 

b. # cd RPKI 

4. Download and install the RIPE NCC RPKI validator software in the VM. 

a. # tar -xvf rpki-validator-app-2.24-dist.tar.gz 

5. Set JAVA_HOME (only if the application complains that it does not see the JAVA_HOME path). 

a. # cd /etc/environment 

i. # nano environment 
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ii. # JAVA_HOME="/usr" 

b. Source it and check echo. 

i. # source /etc/environment 

ii. # Echo $JAVA_HOME 

6. Reboot the server. 

7. Start the RPKI cache. 

a. # . /rpki-validator.sh start 

8. Using a web browser, connect to the validator software that you just installed, by typing 
http://ip-address:8080 into the browser search window, replacing "ip-address" with the internet 
protocol (IP) address of the VM that you just created in step 1. (i.e., http://192.168.1.124:8080). 

9. Once the validator is up, it receives data from the following RIR repositories: AFRINIC, APNIC, 
LACNIC, and RIPE NCC. 

a. To retrieve ROAs from the ARIN repository, download the Trust Anchor Locator (TAL) file 
from https://www.arin.net/resources/rpki/tal.html . 

b. Stop the validator. 

I. # ./rpki-validator. sh stop 

c. Put the file in the TAL sub-directory. 

d. Restart the validator. 

I. # ./rpki-validator. sh start 

2.1.2 Dragon Research RPKI.net Validator Configuration/Installation 

The Dragon Research Labs-developed RPKI.net toolkit contains both a VC and a certificate authority 
(CA). This section discusses the VC only. 

System requirements: Ubuntu 16.04 Xenial server, 32 GB of hard disk, 1 GB of random access memory 
(RAM), and a minimum of one CPU. 

Lab setup: Ubuntu 16.04 Xenial server, rsync, one CPU, 6 GB memory, and running on a VM on VMware 
ESXi. 

For release notes, installation information, and additional information, please view 
https://github.com/dragonresearch/rpki.net/blob/master/doc/quickstart/xenial-rp.md . 
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206 # wget -q -0 

207 /etc/apt/sources.list . d/rpki.list https : //download.rpki . net/APTng/rpki.xenial .1 

208 ist 

209 You may get a message that says that there were errors (i.e., "the following signatures couldn't be 

210 verified because the public key is not available"). To fix this, use the following command, along with the 

211 key that showed up on the error: 

212 # apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 40976EAF437D05B5 

213 Note: 40976EAF437D05B5 is an example. Use the exact key that showed up in the error. 

214 Reference: https://chrisiean.com/fix-apt-get-update-the-following-signatures-couldnt-be-verified- 

215 because-the-public-key-is-not-available/ . 

216 # apt update 

217 # apt install rpki-rp 

218 This should install the VC. Next, access the VC by opening a browser and typing 

219 http://192.168.2.106/rcynic into the search window. 

220 Note: It takes up to an hour to completely update. The proper Uniform Resource Locator (URL) will not 

221 show up until then. Just wait for it. You will see a parent folder directory in the URL during that time. 

222 Once it's ready, charts about the repositories from the different RIRs will show up. 

223 Check to see if the VC is running by entering the following command: 

224 # ps -aux I grep rpki 

225 2.2 RPKI CA and Repository 

226 The delegated model of RPKI for ROA creation and storage requires that two components be set up, 

227 operated, and maintained by the address holder: a CA and a repository. Currently, only the Dragon 

228 Research RPKI.net toolkit provides the components needed to set up a delegated model. 

229 2.2.1 Dragon Research RPKI.net CA and Repository Configuration/Installation 

230 The setup for the CA and repository is different from the setup for the relying-party VC. 

231 System requirements: Ubuntu 16.04 Xenial server, 32 GB of hard disk, 1 GB of RAM, and a minimum of 

232 one CPU. 

233 Lab setup: Ubuntu 16.04 Xenial server, rsync, one CPU, 6 GB memory, and running on a VM on VMware 

234 ESXi. 

235 For release notes, installation information, and additional information, please view 

236 https://github.com/dragonresearch/rpki.net/blob/master/doc/quickstart/xenial-ca.md . 
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Steps for installing the rpki-ca (the CA software) toolkit for this lab build were different from the 
instructions provided by the GitHub documentation. Guidance for the lab build is provided below. 

2.2.1.1 Assumptions 

Prior to installing rpki-ca and rpki-rp (the repository software), ensure that you are working with two 
hosts running the Ubuntu Xenial server. In our setup, we will call one host primary_root (parent) and the 
other host remote_chilcl (child); both are running the Ubuntu Xenial server. 

2.2.1.2 Installation Instructions 

Run the initial setup to install rpki-ca. Follow the steps in the Xenial guide up to "CA Data initialization". 
Execute the steps under rcynic and rsyncd, specifically the "cat" commands that are listed. 

2.2.1.3 Getting rcynic to Run 

1. It's important to note that the rcynic software will NOT be installed correctly. You will need to 
add the following line to /var/spool/cron/crontabs/rcynic: 

*/10 * * * * exec /usr/bin/rcynic-cron 

a. This ensures that the rcynic software will be run periodically to update the certificates. 
This should be done on both hosts. Rcynic is designed to run periodically by default. 

b. Rcynic will error out when external TAL files are called. Delete all repository files in the 
trust-anchors folder. To do this, run the following command: 

# rm /etc/rpki/trust-anchors/* 

1. This should be done on both hosts. 

2. The next step is to edit the /etc/rpki.conf i\\e. 

a. On the host that we will be calling primory_root, make the following changes: 

i. Change the handle to primary_root. 

ii. Change rpkic_server_host to O.O.O.O. 
ill. Change irdb_server_host to O.O.O.O. 
iv. Set run_pubd to yes. 

V. Change pubd_server_host to O.O.O.O. 

This should be sufficient for the changes on primary_root. 
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b. On the host that we will be calling remote_child, make the following changes to 
/etc/rpki.conf: 

I. Change the handle to remote_child. 

ii. Change rpkic_server_host to localhost. 

iii. Change irdb_server_host to localhost. 

iv. Set run_pubd to no. 

V. Change pubd_server_host to prlmary_root. 

This last change means that remote_child will look to primary_root as the 
publication server rather than running its own. To access primary_root, 
remote_child will need a Domain Name System entry for primary_root. 

1) To create this, first find primary_root's IP address by running ifconfig 
on primary_root. In our setup, this IP address is 192.168.2.115. 

2) Then, on remote_child, we add the following line to the /etc/hosts file: 

192.168.2.115: primary_root :(Replacing the IP address with 
whatever IP address is currently assigned to primary_root.) 

At this point, rcynic, rpkic, and rsyncd should all be set up. 

3. On both hosts, run the following commands to reboot the services: 

# systemctl restart xinetd 

# systemctl restart rpki-ca 

2.2.1.4 GUI Setup 

1. Set up the graphical user interface (GUI) on both VMs by running the following command: 

# rpki-manage createsuperuser 

2. Fill in the details appropriately. Verify that each GUI is up by opening a browser and visiting 
https://127.0.0.1 on both hosts. 

2.2.1.5 Root CA Repository Setup 

1. For simplicity, create a folder named /root/CA-stuff on both VMs. Change the directory into this 
folder for both VMs. 

2. Now, we will set up primary_root as a root server for all resources. 
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a. On primary_root, run the following command: 

# rpkic create_identity primary_root 

This will produce a file named primary_root.identity.xml. 

b. Next, run the following command: 

# irpkic configure_root 

This will produce a file named primory_root.primary_root.repository-request.xml. We 
will return to this file later. 

c. Now, run the following command: 

# rpkic -i primary_root extract_root_certificate 

# rpkic -i primary_root extract_root_tal 

These commands will respectively produce a .cer file and a .to/file. 

d. Copy both of these files into the /usr/share/rpkic/rrdp-publication folder. (Note: This 
step may not be necessary.) 

e. Copy the .tal file to /etc/rpki/trust-anchors. This step configures rcynic to look at this 
node as a repository. 

f. Now, we will copy the .tal file from primary_root to remote_child. One way to do this is 
with rsync as follows: 

i. Copy the .tal file to /usr/share/rpki/publication on primary_root. 

ii. On remote_child, run the following command to verify that rsync is working, 
replacing the IP address as appropriate in the command below: 

# rsync rsync://192.168.2.115/rpki 

ill. If the above runs correctly, copy the .tal file, replacing <file> as appropriate in the 
command below: 

# rsync rsync://192.168.2.115/2:pki/<file>.tal /etc/rpki/trust- 
anchors 


Now, primary_root's .tal file should be on both VMs in the /etc/rpki/trust-anchors 
directory. 
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g. We now want to update rcynic. To force it to synchronize, we run the following 
command on both VMs: 

# sudo -u rpki python /usr/bin/rcynic-cron 

I. To verify that rcynic works, visit https://127.0.0.1/rcynic on both VMs. 

h. We return to setting up primary_root. 

i. On primary_root, find the file named primary_root.primary_root.repository- 
request.xml. Once in the right directory, run the following command: 

# irpkic configure_publication_client 
primary_root.primary_root.repository-request.xml 

This should produce a file named primary_root.repository-response. 

ii. With this file, run the following command: 

# irpkic configure_repository primary_root.repository-response 
Now, primary_root should be set up. 

i. On primary_root, visit https://127.0.0.1 and log in. You should see primary_root as a 
repository at the bottom of the page. 

2.2.1.6 Child CA Repository Setup 

1. Our next step is to set up remote_child as a child of primary_root. On remote_child, run the 
following command: 

# rpkic create_identity remote_child 

This will produce a file named remote_child.identity.xml. 

2. We now want to copy this over to primary_root by using rsync. 

a. First, copy the file to /usr/share/rpki/publication on remote_child. 

b. Next, on primary_root, run the following command: 

# rsync rsync://192.168.2.116/rpki/remote_child.identity.xml ./ 

(Replace 192.168.2.116 with remote_child's IP address in the command above.) 

This command will copy the child's identity file to the current working directory on 
primary_root. 
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c. Now, on primary_root, run the following command: 

# rpkic configure_child remote_child.identity.xml 

This will produce a file named primary_root.remote_child.parent-response.xml. 

3. We will copy this file over to remote_child. 

a. To do this, first (on primary_root) copy the file to /usr/share/rpk\/publication. 

b. Next, on remote_child, run the following command: 

# rsync rsync://192.168.2.115/rpki/primary_root.remote_child.parent- 
response .xml ./ 

(Replace the IP address with the appropriate one for primary_root in the command 
above.) 

This command will copy the response to the current working directory on remote_child. 

c. With this file, we now run the following command on remote_child: 

# rpkic configure_parent primary_root.remote_child.parent-response.xml 

This will produce a file named remote_child.primary_root.repository-request.xml. 

4. We will copy this file to primary_root with rsync. 

a. To do this, on remote_child, copy the file to /usr/share/rpki/publication. 

b. Then, on primary_root, run the following command: 

# rsync rsync://192.168.2. 116 / 2 :pki/remote_child.primary_root.repository- 
request.xml ./ 

(Replace the IP address in the command above with remote_child's IP address). 

This will copy the file to the current working directory. 

c. Now, on primary_root, we run the following command: 

# irpkic configure_publication_client 
remote_child.primary_root.repository-request.xml 

This will produce a file named remote_child.repository-response.xml. 

5. We will copy this file to the remote_child by using rsync. 

a. On primary_root, copy the file to /usr/share/rpki/publication. 
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b. Then, on remote_child, run the following command: 

# rsync rsync://192.168.2.115/rpki/remote_child.repository-response.xml 
./ 

(Replace the IP address as necessary in the command above.) 

This will copy the file to the current working directory. 

c. Now, on remote_child, we run the following command: 

# irpkic configure_repository remote_child.repository-response.xml 

2.2.1.7 Run rcynic to Update Root and Child CA Repositories 

This will complete the parent-child setup between primary_root and remote_child. Before verifying, we 
run the following commands on both VMs: 

# irpkic force_piiblication 

# irpkic force_run_now 

# rpkic synchronize 

# sudo -u rpki python /usr/bin/rcynic-cron 

This should force both VMs to fully update everything, including running rcynic. At this point, you should 
verify that primary_root shows up as a parent on remote_child's GUI, and that remote_child shows up 
as a child on primary_root's GUI. Now, we can assign resources. On primary_root's GUI, assign some 
resources to remote_child. Given enough time, remote_child should update its GUI to reflect that it has 
been assigned resources under the resources header on the GUI. 

2.2.1.8 Adding Resources 

When adding resources using the GUI, run the following commands to ensure that rcynic runs to update 
the repository: 

# irpkic force_run_now 

# irpkic synchronize 

# sudo -u rpki python /usr/bin/rcynic-cron 

2.3 BGP-SRx Software Suite 

BGP Secure Routing Extension (BGP-SRx) is an open-source reference implementation and research 
platform for investigating emerging BGP security extensions and supporting protocols, such as RPKI 
Origin Validation and Border Gateway Protocol Security (BGPsec) Path Validation [NIST BGP-SRx) . 
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402 For the latest installation information, please use the Quick Install Guide: 

403 https://bgpsrx.antd.nist.gov/bgpsrx/documents/SRxSoftwareSuite-5.0-QuicklnstallGuide.pdf . 

404 2.4 Firewalls 

405 The firewall used for the lab build is the Palo Alto Next Generation Firewall. The firewall provides 

406 protection against known and unknown threats. In this deployment, only ports and connections 

407 necessary for the build are configured. All other ports and connections are denied. 

408 System requirements: Palo Alto PA-5060 Next Generation Firewall running Version 7.1.10 software. 

409 The configuration shown in Figure 2-1 addressed all ports that are allowed by the firewall. Ports that are 

410 allowed by the firewall are BGP, rsync, and RPKI Repository Delta Protocol (RRDP). All other ports are 

411 denied by the firewall. Figure 2-1 depicts the firewall rules. 
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412 Figure 2-1 Palo Alto Firewall Configuration 
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2.5 Test Harness Topology Configuration 

The configurations provided in this section are the configurations that are used on each of the routers 
when operating in the test harness environment architecture provided in Figure 1-1 in Section 1.2 . 
Initially, Cisco routers were used as routers RTR 1-1, RTR 2-1, and RTR 2-2 in that architecture to perform 
the functional tests. The same tests were then repeated, replacing the Cisco routers with Juniper routers 
as RTR 1-1, RTR 2-1, and RTR 2-2. 

The systems and operating software used for the Cisco routers are as follows: 

■ Cisco 7206 running c7200p-adventerprisrk9-mz.l52-4.s7.bin, with a minimum of 4-gigabit 
Ethernet (GbE) ports. Routers AS 65500 (RTR 2-1) and AS 65501 (RTR 1-1) use this system and 
OS. 

■ Cisco 4331 running ISR4300-universalk9.16.03.04.SPA.bin, with a minimum of 4 GbE ports. 
Router AS 65504A (RTR 2-2) uses this system and OS. 

All Juniper routers have the following requirements: Juniper MX80 running on Juniper Operating System 
(JUNOS) 15.1R6.7, with a minimum of 4 GbE ports. Routers AS 65500 (RTR 2-2), AS 65503-J (RTR 2-1), 
and AS 65505 (RTR 1-1) use this system and OS. 

The BGP-SRx Software Suite traffic generators can run on a CentOS Linux system with minimum 
requirements. 

2.5.1 RTR 1-1 Configuration - Cisco 

RTR 1-1 acts as an exterior border gateway protocol (eBGP) router receiving eBGP routes from BIO-1, as 
depicted in Figure 1-1 . It updates its interior border gateway protocol (IBGP) peer, BIO-2, with iBGP 
updates. VRP data is provided to RTR 1-1 by the RPKI validator. 

hostname AS65501 

I 

interface GigabitEthernetO/1 
ip address 10.90.90.1 255.255.255.0 
ipv6 address FDOO:F:F:1::1/64 


interface FastEthernetO/2 
description VLANl 

ip address 192.168.1.2 255.255.255.0 
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interface GigabitEthernetO/2 


ip address x.x.x.x 255.255.255.252 #Actual IP address to CenturyLink removed. 

I 

interface GigabitEthernetO/3 

ip address y.y.y.y 255.255.255.248 #Actual IP address to CenturyLink removed. 
ipv6 address FDI5:F:F:I::1/64 

I 

router bgp 65501 
bgp log-neighbor-changes 

bgp rpki server tcp 192.168.1.52 port 8282 refresh 5 

neighbor 10.90.90.4 remote-as 65501 

neighbor 192.168.1.50 remote-as 65510 

neighbor 192.168.1.51 remote-as 65511 

neighbor 192.168.1.52 remote-as 65501 

neighbor 192.168.1.53 remote-as 65512 

neighbor FDOO : F: F: 1: : 3 remote-as 65503 

I 

address-family ipv4 

bgp bestpath prefix-validate allow-invalid 

no neighbor 10.90.90.4 activate 

neighbor 192.168.1.50 activate 

neighbor 192.168.1.51 activate 

neighbor 192.168.1.52 activate 

neighbor 192.168.1.52 send-community both 
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neighbor 192.168.1.52 announce rpki state 
neighbor 192.168.1.53 activate 
no neighbor FDOO:F:F:1::3 activate 
exit-address-family 

I 

address-family ipv6 
redistribute connected 
neighbor FDOO:F;F:1::3 activate 
exit-address-family 

I 

ip prefix-list WAN-OUT seq 10 permit 65.118.221.8/29 

I 

route-map rpki permit 10 
match rpki invalid 
set local-preference 100 

I 

route-map RPKI-TEST permit 10 
match ip address prefix-list WAN-OUT 
set community 13698023 

I 

end 
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2.5.2 RTR 2-1 Configuration-Cisco 

RTR 2-1 acts as an eBGP router receiving eBGP routes from BIO-0, and as an iBGP peer providing updates 
to RTR 2-2, as depicted in Figure 1-1 . RTR 2-1 updates another iBGP peer, BIO-2, with iBGP updates. VRP 
data is provided to RTR 1-1 by the RPKI validator. 

hostname AS65500 

I 

interface Loopbackl 
ip address 10.100.0.1 255.255.0.0 
ipv6 address 2010:10:10:10::1/64 

I 

interface GigabitEthernetO/1 
ip address 10.90.90.10 255.255.255.0 
ipv6 address FDOO:F:F:1::10/64 

I 

interface FastEthernetO/2 
ip address 192.168.1.4 255.255.255.0 

I 

interface GigabitEthernetO/2 
ip address 10.99.99.21 255.255.255.252 

I 

interface GigabitEthernetO/3 
description VLANS 

I 

router bgp 65500 
bgp log-neighbor-changes 

bgp rpki server tcp 192.168.1.52 port 8282 refresh 5 
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bgp rpki server tcp 192.168.1.53 port 8282 refresh 5 

neighbor 192.168.1.5 remote-as 65500 

neighbor 192.168.1.50 remote-as 65510 

neighbor 192.168.1.51 remote-as 65511 

neighbor 192.168.1.52 remote-as 65500 

neighbor 192.168.1.53 remote-as 65513 


address-family ipv4 

bgp bestpath prefix-validate allow-invalid 
redistribute connected 
neighbor 192.168.1.5 activate 
neighbor 192.168.1.5 send-community both 
neighbor 192.168.1.5 announce rpki state 
neighbor 192.168.1.50 activate 

neighbor 192.168.1.51 activate 

neighbor 192.168.1.52 activate 

neighbor 192.168.1.52 send-community both 

neighbor 192.168.1.52 announce rpki state 

neighbor 192.168.1.53 activate 

exit-address-family 


route-map 10 permit 10 


end 
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2.5.3 RTR 2-2 Configuration-Cisco 

RTR 2-2 acts as an iBGP router receiving iBGP routes from RTR 2-1, and as an eBGP peer providing 
updates to BIO-6, as depicted in Figure 1-1 . 

version 16.3 

I 

hostname AS65504A 

I 

interface GigabitEthernetO/0/O 
description VLNA5 

ip address 10.40.0.1 255.255.255.0 
ipv6 address FD34;F:F;1;:4/64 

I 

interface GigabitEthernetO/0/1 
description VLN6 

ip address 10.99.99.18 255.255.255.252 
ipv6 address FD24;F;F;1::4/64 

I 

interface GigabitEthernetO/0/2 
ip address 192.168.1.5 255.255.255.0 
ipv6 address 2004;4444;4444;4444;;4/64 

I 

router bgp 65500 
bgp log-neighbor-changes 

bgp rpki server tcp 192.168.1.53 port 8282 refresh 5 
bgp rpki server tcp 192.168.1.52 port 8282 refresh 5 
neighbor 192.168.1.4 remote-as 65500 
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neighbor 192.168.1.53 remote-as 65513 


address-family ipv4 
neighbor 192.168.1.4 activate 
neighbor 192.168.1.4 send-community both 
neighbor 192.168.1.4 announce rpki state 
neighbor 192.168.1.53 activate 
exit-address-family 

I 

route-map NO-EXPORT permit 10 
set community no-export 

I 

end 

2.5.4 RTR 1-1 Configuration - Juniper 

RTR 1-1 acts as an eBGP router receiving eBGP routes from BIO-1, as depicted in Figure 1-1 . RTR 1-1 
updates its iBGP peer, BIO-2, with iBGP updates. VRP data is provided to it by the RPKI validator. 

set system host-name AS65501 

set system login user nccoe uid 2000 

set system login user nccoe class read-only 

set system login user nccoe authentication encrypted-password 
"$5$ 8.Yu2 8ng$LbcoMQ9uqD03.U4VaiG4bg5fWMeaMYAJj r09Aniu8c7" 

set interfaces ge-1/3/0 unit 0 family inet address 192.168.1.12/24 

set interfaces ge-1/3/1 unit 0 family inet 

set interfaces ge-1/3/2 unit 0 family inet 

set interfaces ge-1/3/3 unit 0 family inet 

set interfaces loO unit 0 family inet address 127.0.0.1/32 

set routing-options autonomous-system 65501 
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set routing-options validation group cache session 192.168.1.52 refresh-time 5 


set 

routing-options validation group cache session 192.168.1 

. 52 

port 

8282 

set 

protocols 

bgp 

group 

external-as 65511 

type external 




set 

protocols 

bgp 

group 

external-as 65511 

import validation 




set 

protocols 

bgp 

group 

external-as65511 

export allow-direct 




set 

protocols 

bgp 

group 

external-as 65511 

peer-as 65511 




set 

protocols 

bgp 

group 

external-as 65511 

neighbor 192.168.1. 

51 



set 

protocols 

bgp 

group 

external-as 65510 

type external 




set 

protocols 

bgp 

group 

external-as 65510 

import validation 




set 

protocols 

bgp 

group 

external-as 65510 

export allow-direct 




set 

protocols 

bgp 

group 

external-as 65510 

peer-as 65510 




set 

protocols 

bgp 

group 

external-as 65510 

neighbor 192.168.1. 

50 



set 

protocols 

bgp 

group 

internal-as65501 

type internal 




set 

protocols 

bgp 

group 

internal-as65501 

neighbor 192.168.1. 

52 



set 

protocols 

bgp 

group 

external-as 65512 

type external 




set 

protocols 

bgp 

group 

external-as 65512 

import validation 




set 

protocols 

bgp 

group 

external-as 65512 

export allow-direct 




set 

protocols 

bgp 

group 

external-as65512 

peer-as 65512 




set 

protocols 

bgp 

group 

external-as 65512 

neighbor 192.168.1. 

53 



set 

policy-options policy-statement allow-all from route-filter 

0.0. 

0.0/0 


orlonger 

set policy-options policy-statement allow-all then accept 

set policy-options policy-statement allow-direct term default from protocol 
direct 

set policy-options policy-statement allow-direct term default then accept 

set policy-options policy-statement validation term valid from protocol bgp 

set policy-options policy-statement validation term valid from validation- 
database valid 
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622 

set policy-options 

policy-statement 

validation 

term 

valid then local-preference 

623 

110 







624 

set policy-options 

policy-statement 

validation 

term 

valid then validation-state 

625 

valid 







626 

set policy-options 

policy-statement 

validation 

term 

valid then community add 

627 

origin-validation¬ 

state-valid 






628 

set policy-options 

policy-statement 

validation 

term 

valid then accept 

629 

set policy-options 

policy-statement 

validation 

term 

invalid 

from 

protocol bgp 

630 

set policy-options 

policy-statement 

validation 

term 

invalid 

from 

validation- 

631 

database invalid 







632 

set policy-options 

policy-statement 

validation 

term 

invalid 

then 

local- 

633 

preference 90 







634 

set policy-options 

policy-statement 

validation 

term 

invalid 

then 

validation- 

635 

state invalid 







636 

set policy-options 

policy-statement 

validation 

term 

invalid 

then 

community add 

637 

origin-validation¬ 

state-invalid 






638 

set policy-options 

policy-statement 

validation 

term 

invalid 

then 

accept 

639 

set policy-options 

policy-statement 

validation 

term 

unknown 

from 

protocol bgp 

640 

set policy-options 

policy-statement 

validation 

term 

unknown 

then 

validation- 

641 

state unknown 







642 

set policy-options 

policy-statement 

validation 

term 

unknown 

then 

community add 

643 

origin-validation¬ 

state-unknown 






644 

set policy-options 

policy-statement 

validation 

term 

unknown 

then 

accept 

645 

set policy-options 

community origin- 

-validation- 

-state-invalid members 0x4300:2 


646 set policy-options community origin-validation-state-unknown members 0x4300:1 

647 set policy-options community origin-validation-state-valid members 0x4300:0 
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2.5.5 RTR 2-1 Configuration - Juniper 

RTR 2-1 acts as an eBGP router receiving eBGP routes from BIO-0, and as an iBGP peer providing updates 
to RTR 2-2, as depicted in Figure 1-1 . It updates another iBGP peer, BIO-2, with iBGP updates. VRP data 
is provided to RTR 2-1 by the RPKI validator. 


set system host-name AS65500-J 

set interfaces ge-1/3/0 unit 0 family inet 

set interfaces ge-1/3/1 unit 0 family inet address 192.168.1.14/24 

set interfaces loO unit 0 family inet address 127.0.0.1/32 
set routing-options autonomous-system 65500 

set routing-options validation traceoptions file rpki-trace 
set routing-options validation traceoptions flag all 
deactivate routing-options validation traceoptions 

set routing-options validation group cache session 192.168.1.52 refresh-time 5 

set routing-options validation group cache session 192.168.1.52 port 8282 

set protocols bgp group external-as65511 type external 

set protocols bgp group external-as65511 import validation 

set protocols bgp group external-as65511 export allow-direct 

set protocols bgp group external-as65511 peer-as 65511 

set protocols bgp group external-as65511 neighbor 192.168.1.51 

set protocols bgp group external-as65510 type external 

set protocols bgp group external-as65510 import validation 

set protocols bgp group external-as65510 export allow-direct 

set protocols bgp group external-as65510 peer-as 65510 

set protocols bgp group external-as65510 neighbor 192.168.1.50 

set protocols bgp group internal-as65500 type internal 

set protocols bgp group internal-as65500 neighbor 192.168.1.52 
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set policy-options policy-statement 
orlonger 


allow-all from route-filter 0.0.0.0/0 


set policy-options policy-statement allow-all then accept 

allow-direct term default from protocol 


set policy-options policy-statement 
direct 

set policy-options policy-statement 

set policy-options policy-statement 

set policy-options policy-statement 
database valid 

set policy-options policy-statement 
110 

set policy-options policy-statement 
valid 


allow-direct term default then accept 
validation term valid from protocol bgp 
validation term valid from validation- 

validation term valid then local-preference 

validation term valid then validation-state 


set policy-options policy-statement 
origin-validation-state-valid 


validation term valid then community add 

set policy-options policy-statement validation term valid then accept 


690 

set policy-options 

policy-statement 

validation 

term 

invalid 

from 

protocol bgp 

691 

set policy-options 

policy-statement 

validation 

term 

invalid 

from 

validation- 

692 

database invalid 







693 

set policy-options 

policy-statement 

validation 

term 

invalid 

then 

local- 

694 

preference 90 







695 

set policy-options 

policy-statement 

validation 

term 

invalid 

then 

validation- 

696 

state invalid 







697 

set policy-options 

policy-statement 

validation 

term 

invalid 

then 

community add 

698 

origin-validation¬ 

state-invalid 






699 

set policy-options 

policy-statement 

validation 

term 

invalid 

then 

accept 

700 

set policy-options 

policy-statement 

validation 

term 

unknown 

from 

protocol bgp 

701 

set policy-options 

policy-statement 

validation 

term 

unknown 

then 

validation- 

702 

state unknown 







703 

set policy-options 

policy-statement 

validation 

term 

unknown 

then 

community add 

704 

origin-validation¬ 

state-unknown 






705 

set policy-options 

policy-statement 

validation 

term 

unknown 

then 

accept 
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715 

716 
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718 

719 

720 
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722 

723 

724 

725 

726 

727 

728 

729 

730 

731 

732 


set policy-options community origin-validation-state-invalid members 0x4300:0:2 
set policy-options community origin-validation-state-unknown members 0x4300:0:1 
set policy-options community origin-validation-state-valid members 0x4300:0:0 


2.5.6 RTR 2-2 Configuration - Juniper 

RTR 2-2 acts as an iBGP router receiving iBGP routes from RTR 2-1, and as an eBGP peer providing 
updates to BIO-6, as depicted in Figure 1-1 . 


set system host-name AS65500 

set interfaces ge-1/3/0 unit 0 family inet address 192.168.1.15/24 

set interfaces ge-1/3/1 unit 0 

set interfaces ge-1/3/2 unit 0 

set interfaces ge-1/3/3 unit 0 

set interfaces loO unit 0 family inet 

set routing-options autonomous-system 65500 

set routing-options validation group cache session 192.168.1.52 refresh-time 

set routing-options validation group cache session 192.168.1.52 port 8282 

set routing-options validation group cache session 192.168.1.53 refresh-time 

set routing-options validation group cache session 192.168.1.53 port 8282 

set protocols bgp group internal-as65500 type internal 

set protocols bgp group internal-as65500 neighbor 192.168.1.14 

set protocols bgp group external-as65513 type external 

set protocols bgp group external-as65513 import validation 

set protocols bgp group external-as65513 export allow-direct 

set protocols bgp group external-as65513 peer-as 65513 

set protocols bgp group external-as65513 neighbor 192.168.1.53 

set policy-options policy-statement allow-all from route-filter 0.0.0.0/0 
orlonger 

set policy-options policy-statement allow-all then accept 


5 


5 
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733 set policy-options policy-statement allow-direct term default from protocol 

734 direct 


735 set policy-options policy-statement allow-direct term default then accept 


736 

set policy-options 

policy-statement 

validation 

term 

valid from protocol bgp 

737 

738 

set policy-options 
database valid 

policy-statement 

validation 

term 

valid from validation- 

739 

740 

set policy-options 
110 

policy-statement 

validation 

term 

valid then local-preference 

741 

742 

set policy-options 
valid 

policy-statement 

validation 

term 

valid then validation-state 

743 

744 

set policy-options 
origin-validation¬ 

policy-statement 
state-valid 

validation 

term 

valid then community add 

745 

set policy-options 

policy-statement 

validation 

term 

valid then accept 

746 

set policy-options 

policy-statement 

validation 

term 

invalid 

from 

protocol bgp 

747 

748 

set policy-options 
database invalid 

policy-statement 

validation 

term 

invalid 

from 

validation- 

749 

750 

set policy-options 
preference 90 

policy-statement 

validation 

term 

invalid 

then 

local- 

751 

752 

set policy-options 
state invalid 

policy-statement 

validation 

term 

invalid 

then 

validation- 

753 

754 

set policy-options 
origin-validation¬ 

policy-statement 
state-invalid 

validation 

term 

invalid 

then 

community add 

755 

set policy-options 

policy-statement 

validation 

term 

invalid 

then 

accept 

756 

set policy-options 

policy-statement 

validation 

term 

unknown 

from 

protocol bgp 

757 

758 

set policy-options 
state unknown 

policy-statement 

validation 

term 

unknown 

then 

validation- 

759 

760 

set policy-options 
origin-validation¬ 

policy-statement 
state-unknown 

validation 

term 

unknown 

then 

community add 

761 

set policy-options 

policy-statement 

validation 

term 

unknown 

then 

accept 


762 set policy-options community origin-validation-state-invalid members 0x4300:2 

763 set policy-options community origin-validation-state-invalid members 0x43:100:2 

764 set policy-options community origin-validation-state-unknown members 0x4300:1 
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765 

766 

767 

768 

769 

770 

771 

111 . 

773 

774 

775 

776 

111 

778 

779 

780 

781 

782 

783 

784 

785 

786 

787 

788 

789 

790 

791 

792 

793 

794 


set policy-options community origin-validation-state-valid members 0x4300:0 


2.5.7 Traffic Generator BIO Configuration 

sk;i_file = "/var/lib/key-volt/ski-list. txt" ; 
ski_key_loc = "/var/lib/key-volt/"; 
preload_eckey = false; 
mode = "BGP"; 
max = 0; 

only_extended_length = true; 
session = ( 

{ 

disconnect = 0; 
ext_msg_cap = true; 

ext msg liberal = true; 
bgpsec_v4_snd = false; 
bgpsec_v4_rcv = false; 
bgpsec_v6_snd = false; 
bgpsec_v6_rcv = false; update = ( 

) ; 

incl_global_updates = true; 
algo_id = 1; 

signature_generation = "BIO"; 
null_signature_mode = "FAKE"; 

fake_signature = "IBADBEEFDEADFEED" "2BADBEEFDEADFEED" 

"3BADBEEFDEADFEED" "4BADBEEFDEADFEED" 
"5BADBEEFDEADFEED" "6BADBEEFDEADFEED" 
"7BADBEEFDEADFEED" "8BADBEEFDEADFEED" 
"ABADBEEFFACE"; 

fake_ski = "0102030405060708" "090A0B0C0D0E0F10" 

"11121314"; 

printOnSend = { 


NIST SP 1800-14C: Protecting the Integrity of Internet Routing 


31 



795 

796 

797 

798 

799 

800 

801 

802 

803 

804 

805 

806 

807 

808 

809 

810 

811 

812 

813 

814 

815 

816 

817 

818 

819 

820 

821 

822 

823 

824 


update 


true ; 


}; 


printOnReceive = { 
update. = true; 

notification = true; 
unknown = true; 

}; 

printSimple = true; 

printPollLoop = false; 
printOnInvalid = false; 


} 

) ; 

update = ( 


2.5. 7.1 AS- Peer Configuration: BIO-0 (AS 65510) - RTR-1-1 (AS 65501) 

asn =65510; 

bgp_ident = "192.168.1.50"; 
hold timer = 180; 


peer_asn = 65501; 

# For CISCO replace x with 2, For JUNIPER replace x with 12 
peer_ip = "192.168.1.x"; 

peer_port = 179; 

2.5.7.2 /\S - Peer Configuration: BIO-0 (AS 65510) - RTR-2-1 (AS 65500) 

asn = 65510; 

bgp_ident = "192.168.1.50"; 
hold timer = 180; 


peer_asn = 65500; 
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826 

827 

828 

829 

830 

831 

832 

833 
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836 
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838 
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840 
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843 
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845 

846 

847 

848 

849 

850 

851 

852 

853 

854 


# For CISCO replace x with 4, For JUNIPER replace x with 14 


peer_ip = "192.168.1.x"; 

peer_port = 179; 

2.5.7.3 /\S - Peer Configuration: BIO-1 (AS 65511) - RTR-1-1 (AS 65501) 

asn = 65511; 

bgp_ident = "192.168.1.51"; 
hold timer = 180; 


peer_asn = 65500; 

# For CISCO replace x with 2, For JUNIPER replace x with 12 
peer_ip = "192.168.1.x"; 

peer_port = 179; 

2.5.7.4 >AS - Peer Configuration: BIO-1 (AS 65511) - RTR-2-1 (AS 65500) 

asn =65511; 

bgp_ident = "192.168.1.51"; 
hold timer = 180; 


peer_asn = 65500; 

# For CISCO replace x with 4, For JUNIPER replace x with 14 

peer_ip = "192.168.1.x"; 

peer_port = 179; 

2.5.7.5 /^S - Peer Configuration: BIO-2 (AS 65501) - RTR-1-1 (AS 65501) 

asn =65501; 

bgp_ident = "192.168.1.52"; 
hold_timer = 180; 

peer_asn = 65501; 

# For CISCO replace x with 2, For JUNIPER replace x with 12 

peer_ip = "192.168.1.x"; 

peer_port = 179; 
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866 

867 
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874 

875 

876 

877 

878 

879 

880 

881 


2.5.7.6 >\S - Peer Configuration: BiO-3 (AS 65500) - RTR-2-1 (AS 65500) 

asn =65500; 

bgp_ident = "192.168.1.52"; 
hold timer = 180; 


peer_asn = 65500; 

# For CISCO replace x with 4, For JUNIPER replace x with 14 
peer_ip = "192.168.1.x"; 

peer_port = 179; 

2.5.7.7 /\S - Peer Configuration: BIO-5 (AS 65512) - RTR-1-1 (AS 65500) 

asn =65512; 

bgp_ident = "192.168.1.53"; 
hold timer = 180; 


peer_asn = 65501; 

# For CISCO replace x with 2, For JUNIPER replace x with 12 

peer_ip = "192.168.1.x"; 

peer_port = 179; 

2.5. 7.8 AS - Peer Configuration: BIO-6 (AS 65513) - RTR-1-1 (AS 65513) 

asn =65513; 

bgp_ident = "192.168.1.53"; 
hold_timer = 180; 

peer_asn = 65500; 

# For CISCO replace x with 4, For JUNIPER replace x with 14 

peer_ip = "192.168.1.x"; 

peer_port = 179; 


NIST SP 1800-14C: Protecting the Integrity of Internet Routing 


34 



882 

883 

884 

885 

886 

887 

888 

889 

890 

891 

892 

893 

894 

895 

896 

897 

898 

899 

900 

901 

902 

903 

904 

905 

906 

907 

908 

909 

910 

911 


2.6 Live Data Configuration 

The configurations provided in this section are the configurations that are used on each of the routers 
when operating in the live data environment architecture shown in Figure 1-2 . Live BGP data and RPKI 
data can be retrieved in this environment. The architecture is organized into eight separate networks, 
each of which is designed to represent a different AS. 

The systems and operating software used for the Cisco routers are as follows: 

■ Cisco 7206 running c7200p-adventerprisrk9-mz.l52-4.s7.bin, with a minimum of 4 GbE ports. 
Routers AS 65500, AS 65501, and AS 65503 use this system and OS. 

■ Cisco 4331 running ISR4300-universalk9.16.03.04.SPA.bin, with a minimum of 4 GbE ports. 
Routers AS 65504A and AS 65504B use this system and OS. 

■ Cisco 2921 running c2900-universalk9-mz-SPA.152-4.M6.bin, with a minimum of 4 GbE ports. 
Routers AS 65507 and AS 65508 use this system and OS. 

■ Cisco Internetwork Operating System (lOS) XRv 9000 router Version 6.4.1 running on VMware 
ESXi using the xrv9k-fullk9-x.vrr-6.4.1.ova file. 

All Juniper routers have the following requirements: Juniper MX80 running on JUNOS 15.1R6.7, with a 
minimum of 4 GbE ports. Routers AS 65502 and AS 65505 use this system and OS. 

RPKI validators and repositories are configured based on Section 2.1 and Section 2.2 . Live ROV data is 
retrieved from the five trust anchors, and lab ROA data is retrieved from the lab delegated model of the 
local RPKI repository. 

Note: Real IP addresses and AS numbers were removed from the configuration. 

2.6.1 CenturyLink Configuration Router AS 65501 - Cisco 

To receive a full BGP route table, CenturyLink provided a physical link connecting the NCCoE lab with an 
eBGP peering. The configuration below illustrates the eBGP peering. An additional configuration for this 
router, related to the lab build, is provided in Section 2.5.3 . 

version 15.2 

I 

hostname AS65501 

I 

ipv6 unicast-routing 
ipv6 cef 
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912 

913 
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916 
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920 
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927 

928 
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930 
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932 

933 

934 

935 

936 

937 


interface GigabitEthernetO/1 


ip address 10.90.90.1 255.255.255.0 
ipv6 address FDOO:F;F;1::1/64 

I 

interface FastEthernetO/2 
description VLANl 

ip address 192.168.1.2 255.255.255.0 

I 

interface GigabitEthernetO/2 
ip address a.a.a.a 255.255.255.252 

I 

interface GigabitEthernetO/3 
ip address c.c.c.c 255.255.255.248 

ipv6 address FD15:F;F:1::1/64 

I 

router bgp aaa 
bgp log-neighbor-changes 
neighbor a.a.a.b remote-as bbb 

I 

address-family ipv4 
network c.c.c.d mask 255.255.255.248 
neighbor a.a.a.b activate 
neighbor a.a.a.b send-community 
neighbor a.a.a.b soft-reconfiguration inbound 
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956 

957 

958 

959 

960 

961 

962 

963 


neighbor a.a.a.b route-map RPKI-TEST out 


exit-address-family 

I 

ip prefix-list WAN-OUT seq 10 permit c.c.c.d/29 

ipv6 router rip prod 

I 

route-map rpki permit 10 
match rpki invalid 
set local-preference 100 

I 

route-map RPKI-TEST permit 10 
match ip address prefix-list WAN-OUT 
set community 13698023 

I 

end 

2.6.2 Router AS 65500 Configuration - Cisco 

Router AS 65500 represents an ISP. For the lab build, this router originates BGP updates from its own AS 
and receives and sends routes to and from its eBGP peers. 

hostname AS65500 

I 

ip cef 

ipv6 unicast-routing 

ipv6 cef 

I 

interface Loopbackl 
ip address 10.10.0.1 255.255.0.0 
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ipv6 address FDIO:10:10:10::1/64 
ipv6 rip prod enable 

I 

interface GigabitEthernetO/1 
ipv6 address FDOO:F:F:1::1/64 
ipv6 rip prod enable 

I 

interface FastEthernetO/2 
description VLANl 

ip address 192d68d.2 255.255.255.0 
ipv6 address FDOl:F;F:1::2/64 
ipv6 rip prod enable 

I 

interface GigabitEthernetO/2 
ip address a.a.a.a 255.255.255.252 

I 

interface GigabitEthernetO/3 
ip address c.c.c.c 255.255.255.248 
ipv6 address FDl5:F;F:1::1/64 

I 

router rip 
version 2 
network 10.0.0.0 
network 192.168.1.0 
no auto-summary 
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router bgp aaa 
bgp log-neighbor-changes 
neighbor a.a.a.b remote-as bbb 


address-family ipv4 
network c.c.c.d mask 255.255.255.248 


neighbor a.a.a.b activate 
neighbor a.a.a.b send-community 
neighbor a.a.a.b soft-reconfiguration inbound 
neighbor a.a.a.b route-map RPKI-TEST out 


exit-address-family 

I 

ip route 10.20.0.0 255.255.0.0 192.168.1.3 
ip route 10.30.0.0 255.255.0.0 192.168.1.3 
ip route 10.40.0.0 255.255.0.0 192.168.1.3 
ip route 10.50.0.0 255.255.0.0 192.168.1.3 
ip route 10.70.0.0 255.255.0.0 192.168.1.3 
ip route 10.80.0.0 255.255.0.0 192.168.1.3 
ip route 10.90.90.0 255.255.255.0 192.168.1.3 
ip route 10.97.74.0 255.255.255.0 192.178.1.1 
ip route 10.99.99.0 255.255.255.0 192.168.1.3 


ip prefix-list WAN-OUT seq 10 permit c.c.c.d /29 
ipv6 router rip prod 


route-map rpki permit 10 
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match rpki invalid 


set local-preference 100 

I 

route-map RPKI-TEST permit 10 
match ip address prefix-list WAN-OUT 
set community 13698023 

I 

end 

2.6.3 Router 65501 Configuration - Cisco 

Router AS 65501 represents an ISP. As indicated in Section 2.5.1, this router peers with the CenturyLink 
router to receive a full BGP routing table. For the lab build, this router originates BGP updates from its 
own AS and receives and sends routes to and from its eBGP peers. It is the gateway for all devices in the 
lab, allowing ROAs from RIRs to be retrieved by RPKI validators. It also peers with stub AS A65505. 

hostname AS65501 

I 

ip cef 

ipv6 unicast-routing 

ipv6 cef 

I 

interface Loopbackl 
ip address 10.10.0.1 255.255.0.0 
ipv6 address FDIO:10:10:10: : 1/64 
ipv6 rip prod enable 

I 

interface GigabitEthernetO/1 
ipv6 address FDOO:F:F:1::1/64 
ipv6 rip prod enable 
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interface FastEthernetO/2 


ip address 192.168.1.2 255.255.255.0 
ipv6 address FDOl:F:F:1::2/64 
ipv6 rip prod enable 

I 

interface GigabitEthernetO/2 
ip address a.a.a.a 255.255.255.252 

I 

interface GigabitEthernetO/3 
ip address c.c.c.c 255.255.255.248 
ipv6 address FDl5:F;F:1::1/64 

I 

router rip 
version 2 
network 10.0.0.0 
network 192.168.1.0 
no auto-summary 

I 

router bgp aaa 
bgp log-neighbor-changes 
neighbor a.a.a.b remote-as bbb 

I 

address-family ipv4 
network c.c.c.d mask 255.255.255.248 
neighbor a.a.a.b activate 


NIST SP 1800-14C: Protecting the Integrity of Internet Routing 


41 



1069 

1070 

1071 

1072 

1073 

1074 

1075 

1076 

1077 

1078 

1079 

1080 

1081 

1082 

1083 

1084 

1085 

1086 

1087 

1088 

1089 

1090 

1091 

1092 

1093 

1094 


neighbor a.a.a.b send-community 


neighbor a.a.a.b soft-reconfiguration inbound 
neighbor a.a.a.b route-map RPKI-TEST out 


exit-address-family 

I 

ip route 10.20.0.0 255.255.0.0 192.168.1.3 
ip route 10.30.0.0 255.255.0.0 192.168.1.3 
ip route 10.40.0.0 255.255.0.0 192.168.1.3 
ip route 10.50.0.0 255.255.0.0 192.168.1.3 
ip route 10.70.0.0 255.255.0.0 192.168.1.3 
ip route 10.80.0.0 255.255.0.0 192.168.1.3 
ip route 10.90.90.0 255.255.255.0 192.168.1.3 
ip route 10.97.74.0 255.255.255.0 192.178.1.1 
ip route 10.99.99.0 255.255.255.0 192.168.1.3 


ip prefix-list WAN-OUT seq 10 permit c.c.c.d /29 
ipv6 router rip prod 


route-map rpki permit 10 
match rpki invalid 
set local-preference 100 


route-map RPKI-TEST permit 10 
match ip address prefix-list WAN-OUT 
set community 13698023 
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end 


2.6.4 Router AS 65502 Configuration - Juniper 

Router AS 65502 represents an ISP using a Juniper router. For the lab build, this router originates BGP 
updates from its own AS and receives and sends routes to and from its eBGP peers. It also provides 
eBGP routes to stub AS 65504. 


set system host-name AS65502 

set interfaces ge-1/3/0 unit 0 family inet address 10.90.90.2/24 

set interfaces ge-1/3/0 unit 0 family inet6 address fdOO:f:f:1::2/64 

set interfaces ge-1/3/1 unit 0 family inet address 10.99.99.17/30 

set interfaces ge-1/3/1 unit 0 family inet6 address fd24:f:f:1: : 2/64 

set interfaces ge-1/3/2 unit 0 family inet address 10.99.99.25/30 

set interfaces ge-1/3/2 unit 0 family inet6 address fd25:f:f:1::2/64 

set interfaces ge-1/3/3 unit 0 family inet address 10.20.0.1/16 

set interfaces ge-1/3/3 unit 0 family inet6 address 2020 : 2020 : 2020:1: : 2/64 

set interfaces loO unit 0 family inet address 127.0.0.1/32 

set routing-options validation group cache session 192.168.1.146 port 8282 

set policy-options policy-statement allow-all from route-filter 0.0.0.0/0 
orlonger 

set policy-options policy-statement allow-all then accept 

set routing-instances rpki instance-type virtual-router 

set routing-instances rpki interface ge-1/3/0.0 

set routing-instances rpki interface ge-1/3/1.0 

set routing-instances rpki interface ge-1/3/2.0 

set routing-instances rpki interface ge-1/3/3.0 

set routing-instances rpki interface loO.l 

set routing-instances rpki routing-options router-id 2.2.2.2 

set routing-instances rpki routing-options autonomous-system 65502 
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1122 

set routing-instances 

rpki 

protocols 

bgp 

group 

external-as65500 

type external 

1123 

1124 

set routing-instances 
all 

rpki 

protocols 

bgp 

group 

external-as65500 

import allow- 

1125 

1126 

set routing-instances 
all 

rpki 

protocols 

bgp 

group 

external-as65500 

export allow- 

1127 

set routing-instances 

rpki 

protocols 

bgp 

group 

external-as65500 

peer-as 65500 

1128 

1129 

set routing-instances 
10.90.90.10 

rpki 

protocols 

bgp 

group 

external-as65500 

neighbor 

1130 

1131 

set routing-instances 
fdOO:f:f:1: : 10 

rpki 

protocols 

bgp 

group 

external-as65500 

neighbor 

1132 

set routing-instances 

rpki 

protocols 

bgp 

group 

external-as65501 

type external 

1133 

1134 

set routing-instances 
all 

rpki 

protocols 

bgp 

group 

external-as65501 

import allow- 

1135 

1136 

set routing-instances 
all 

rpki 

protocols 

bgp 

group 

external-as65501 

export allow- 

1137 

set routing-instances 

rpki 

protocols 

bgp 

group 

external-as65501 

peer-as 65501 

1138 

1139 

set routing-instances 
10.90.90.1 

rpki 

protocols 

bgp 

group 

external-as65501 

neighbor 

1140 

1141 

set routing-instances 
fdOO:f:f:1;:1 

rpki 

protocols 

bgp 

group 

external-as65501 

neighbor 

1142 

set routing-instances 

rpki 

protocols 

bgp 

group 

external-as65503 

type external 

1143 

1144 

set routing-instances 
all 

rpki 

protocols 

bgp 

group 

external-as65503 

import allow- 

1145 

1146 

set routing-instances 
all 

rpki 

protocols 

bgp 

group 

external-as65503 

export allow- 

1147 

set routing-instances 

rpki 

protocols 

bgp 

group 

external-as65503 

peer-as 65503 

1148 

1149 

set routing-instances 
10.90.90.3 

rpki 

protocols 

bgp 

group 

external-as65503 

neighbor 

1150 

1151 

set routing-instances 
fd00:f:f:l::3 

rpki 

protocols 

bgp 

group 

external-as65503 

neighbor 

1152 

set routing-instances 

rpki 

protocols 

bgp 

group 

external-as65505 

type external 

1153 

1154 

set routing-instances 
all 

rpki 

protocols 

bgp 

group 

external-as65505 

import allow- 
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1155 

1156 

set routing-instances 
all 

rpki 

protocols 

bgp 

group 

external-as65505 

export allow- 

1157 

set routing-instances 

rpki 

protocols 

bgp 

group 

external-as65505 

peer-as 65505 

1158 

1159 

set routing-instances 
fd25:f:f:1;:5 

rpki 

protocols 

bgp 

group 

external-as65505 

neighbor 

1160 

1161 

set routing-instances 
10.99.99.26 

rpki 

protocols 

bgp 

group 

external-as65505 

neighbor 

1162 

set routing-instances 

rpki 

protocols 

bgp 

group 

external-as65504 

type external 

1163 

1164 

set routing-instances 
all 

rpki 

protocols 

bgp 

group 

external-as65504 

import allow- 

1165 

1166 

set routing-instances 
all 

rpki 

protocols 

bgp 

group 

external-as65504 

export allow- 

1167 

set routing-instances 

rpki 

protocols 

bgp 

group 

external-as65504 

peer-as 65504 

1168 

1169 

set routing-instances 
10.99.99.18 

rpki 

protocols 

bgp 

group 

external-as65504 

neighbor 

1170 

1171 

set routing-instances 
fd24:f:f:1:;4 

rpki 

protocols 

bgp 

group 

external-as65504 

neighbor 


1172 2.6.5 Router AS 65503 Configuration - Cisco 

1173 Router AS 65503 represents an ISP without ROV capabilities. For the lab build, this router originates BGP 

1174 updates from its own AS and receives and sends routes to and from its eBGP peers without performing 

1175 BGP origin validation. This router peers with two transit routers, AS 65500 and AS 65502, as well as two 

1176 stub ASes, AS 65504 and AS 65507. 

1177 hostname AS65503 

1178 ! 

1179 ip cef 

1180 ipv6 unicast-routing 

1181 ipv6 cef 

1182 ! 

1183 interface Loopbackl 

1184 ip address 10.30.0.1 255.255.0.0 

1185 ipv6 address 2003:3333:3333:3333::1/64 
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1186 

1187 

1188 

1189 

1190 

1191 

1192 

1193 

1194 

1195 

1196 

1197 

1198 

1199 

1200 

1201 

1202 

1203 

1204 

1205 

1206 

1207 

1208 

1209 

1210 

1211 


interface GigabitEthernetO/1 


ip address 10.90.90.3 255.255.255.0 
ipv6 address FDOO:F:F:1::3/64 

I 

interface FastEthernetO/2 
ip address 192.168.1.251 255.255.255.0 

I 

interface GigabitEthernetO/2 
ip address 10.99.99.13 255.255.255.252 

I 

interface GigabitEthernetO/3 
description VLAN7 

ip address 10.99.99.21 255.255.255.252 
ipv6 address FD37:F;F:1::1/64 


router bgp 65503 
bgp log-neighbor-changes 

bgp rpki server tcp 192.168.1.146 port 8282 refresh 10 

neighbor 10.90.90.1 remote-as 65501 

neighbor 10.90.90.2 remote-as 65502 

neighbor 10.90.90.10 remote-as 65500 

neighbor 10.99.99.14 remote-as 65504 

neighbor 10.99.99.22 remote-as 65507 

neighbor FDOO:F:F:1::1 remote-as 65501 

neighbor FDOO:F;F;1::2 remote-as 65502 
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1212 

1213 

1214 

1215 

1216 

1217 

1218 

1219 

1220 

1221 

1222 

1223 

1224 

1225 

1226 

1227 

1228 

1229 

1230 

1231 

1232 

1233 

1234 

1235 

1236 

1237 


neighbor FDOO:F:F:1::10 remote-as 65500 


neighbor FD34;F;F;1::4 remote-as 65504 
neighbor FD34;F;F;1::7 remote-as 65507 

I 

address-family ipv4 
redistribute connected 
redistribute static 
neighbor 10.90.90.1 activate 
neighbor 10.90.90.2 activate 
neighbor 10.90.90.10 activate 
neighbor 10.99.99.14 activate 
neighbor 10.99.99.22 activate 
no neighbor FDOO:F:F:1::1 activate 
no neighbor FDOO:F:F:1::2 activate 
no neighbor FDOO:F;F:1::10 activate 
no neighbor FD34:F:F;1:;4 activate 
no neighbor FD34;F:F:1::7 activate 
exit-address-family 

I 

address-family ipv6 
redistribute connected 
neighbor FDOO:F;F:1:;1 activate 
neighbor FDOO:F;F:1::2 activate 
neighbor FDOO:F;F:1::10 activate 
neighbor FD34:F;F;1:;4 activate 
exit-address-family 
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1238 

1239 

1240 

1241 

1242 

1243 

1244 

1245 

1246 

1247 

1248 

1249 

1250 

1251 

1252 

1253 

1254 

1255 

1256 

1257 

1258 

1259 

1260 

1261 

1262 

1263 


ipv6 router rip prod 


I 

end 

2.6.6 Router AS 65504A Configuration - Cisco 

Router AS 65504A represents an enterprise edge router for AS 65504. For the lab build, this router 
originates BGP updates from its own AS and receives and sends routes to and from its eBGP peer, AS 
65502. It peers with Router AS 65504B to exchange iBGP routes. 

hostname AS65504A 

I 

ipv6 unicast-routing 

I 

interface Loopbackl 
ip address 10.40.1.1 255.255.255.0 

I 

interface GigabitEthernetO/0/O 
ip address 10.40.0.1 255.255.255.0 
ipv6 address FDOO:F:F:1::40/64 
ipv6 address FD34;F:F;1:;4/64 

I 

interface GigabitEthernetO/0/1 
ip address 10.99.99.18 255.255.255.252 
ipv6 address FD24;F;F;1:;4/64 

I 

interface GigabitEthernetO/0/2 
ip address 10.40.4.1 255.255.255.0 


NIST SP 1800-14C: Protecting the Integrity of Internet Routing 


48 



1264 

1265 

1266 

1267 

1268 

1269 

1270 

1271 

1272 

1273 

1274 

1275 

1276 

1277 

1278 

1279 

1280 

1281 

1282 

1283 

1284 

1285 

1286 

1287 

1288 

1289 


ipv6 address 2004:4444;4444:4444::4/64 


router bgp 65504 
bgp log-neighbor-changes 
neighbor 10.40.0.2 remote-as 65504 
neighbor 10.99.99.17 remote-as 65502 
neighbor FD24;F:F:1::2 remote-as 65502 

I 

address-family ipv4 
redistribute connected 
redistribute static 
no neighbor 10.40.0.2 activate 
neighbor 10.99.99.17 activate 
no neighbor FD24:F:F:1::2 activate 
exit-address-family 

I 

address-family ipv6 
redistribute connected 
neighbor FD24:F;F:1::2 activate 
exit-address-family 

I 

ip route 10.40.2.0 255.255.255.0 10.40.0.2 

I 

route-map NO-EXPORT permit 10 
set community no-export 
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1290 

1291 

1292 

1293 

1294 

1295 

1296 

1297 

1298 

1299 

1300 

1301 

1302 

1303 

1304 

1305 

1306 

1307 

1308 

1309 

1310 

1311 

1312 

1313 

1314 

1315 


end 


2.6.7 Router AS 65504B Configuration - Cisco 

Router AS 65504B represents an enterprise edge router for AS 65504. For the lab build, this router 
originates BGP updates from its own AS and receives and sends routes to and from its eBGP peer, AS 
65503. It peers with Router AS 65504Ato exchange iBGP routes. 

hostname AS65504B 

I 

ipv6 unicast-routing 

I 

interface Loopbackl 
ip address 10.40.2.1 255.255.255.0 
ipv6 address 4040:4040:4040:4242::1/64 

I 

interface GigabitEthernetO/0/0 
ip address 10.99.99.14 255.255.255.252 
ipv6 address FD34;F;F:1:;4/64 

I 

interface GigabitEthernetO/0/1 
ip address 10.40.0.2 255.255.255.0 
ipv6 address FD40:F;F:1::2/64 

I 

router bgp 65504 
bgp log-neighbor-changes 
neighbor 10.40.0.1 remote-as 65504 
neighbor 10.99.99.13 remote-as 65503 
neighbor FD34;F:F:1::2 remote-as 65503 


NIST SP 1800-14C: Protecting the Integrity of Internet Routing 


50 



1316 

1317 

1318 

1319 

1320 

1321 

1322 

1323 

1324 

1325 

1326 

1327 

1328 

1329 

1330 

1331 

1332 

1333 

1334 

1335 

1336 

1337 

1338 

1339 

1340 

1341 


neighbor FD40:F:F:1::1 remote-as 65504 


address-family ipv4 
redistribute connected 
no neighbor 10.40.0.1 activate 
neighbor 10.99.99.13 activate 
no neighbor FD34:F:F:1::2 activate 
no neighbor FD40:F;F:1::1 activate 
exit-address-family 

I 

address-family ipv6 
redistribute connected 
neighbor FD34:F;F:1::2 activate 
neighbor FD40:F;F:1::1 activate 
exit-address-family 

I 

route-map NO-EXPORT permit 10 
set community no-export 

I 

end 

2.6.8 Router AS 65505 Configuration - Juniper 

Router AS 65505 represents an enterprise edge router. For the lab build, this router originates BGP 
updates from its own AS and receives and sends routes to and from its eBGP peers, AS 65501 and AS 
65502. 

set system host-name AS65505 

set interfaces ge-1/3/0 unit 0 family inet 
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1342 

1343 

1344 

1345 

1346 

1347 

1348 

1349 

1350 

1351 

1352 

1353 

1354 

1355 

1356 

1357 

1358 

1359 

1360 

1361 

1362 

1363 

1364 

1365 

1366 

1367 

1368 


set interfaces ge-1/3/0 unit 0 family inet6 

set interfaces ge-1/3/1 unit 0 family inet address 10.99.99.2/30 

set interfaces ge-1/3/1 unit 0 family inet6 address fdl5:f:f:1::5/64 

set interfaces ge-1/3/2 unit 0 family inet address 10.99.99.26/30 

set interfaces ge-1/3/2 unit 0 family inet6 address fd25:f:f:1::5/64 

set interfaces ge-1/3/3 unit 0 family inet address 10.50.0.1/16 

set interfaces ge-1/3/3 unit 0 family inet6 address 5050:5050:5050:1::5/64 

set interfaces loO unit 0 family inet address 127.0.0.1/32 

set routing-options autonomous-system 65505 

set routing-options validation group cache session 192.168.1.146 port 8282 


set 

protocols 

bgp 

group 

external-as 65501 

type external 

set 

protocols 

bgp 

group 

external-as 65501 

import validation 

set 

protocols 

bgp 

group 

external-as 65501 

export allow-direct 

set 

protocols 

bgp 

group 

external-as 65501 

peer-as 65501 

set 

protocols 

bgp 

group 

external-as 65501 

neighbor 10.99.99.1 

set 

protocols 

bgp 

group 

external-as65501 

neighbor fdl5:f:f:l: 

set 

protocols 

bgp 

group 

external-as 65502 

type external 

set 

protocols 

bgp 

group 

external-as 65502 

import validation 

set 

protocols 

bgp 

group 

external-as 65502 

export allow-direct 

set 

protocols 

bgp 

group 

external-as 65502 

peer-as 65502 

set 

protocols 

bgp 

group 

external-as 65502 

neighbor 10.99.99.25 

set 

protocols 

bgp 

group 

external-as 65502 

neighbor fd25:f:f;l; 


set policy-options policy-statement allow-all from route-filter 0.0.0.0/0 
orlonger 

set policy-options policy-statement allow-all then accept 

set policy-options policy-statement allow-direct term default from protocol 
direct 
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1369 

set 

policy-options 

policy-statement 

allow-direct term default then accept 


1370 

set 

policy-options 

policy-statement 

validation 

term 

valid from protocol bgp 

1371 

set 

policy-options 

policy-statement 

validation 

term 

valid from validation- 


1372 

database valid 








1373 

set 

policy-options 

policy-statement 

validation 

term 

valid then local-preference 

1374 

110 









1375 

set 

policy-options 

policy-statement 

validation 

term 

valid then validation- 

-state 

1376 

valid 








1377 

set 

policy-options 

policy-statement 

validation 

term 

valid then accept 


1378 

set 

policy-options 

policy-statement 

validation 

term 

invalid 

from 

protocol 

bgp 

1379 

set 

policy-options 

policy-statement 

validation 

term 

invalid 

from 

validation- 

1380 

database invalid 








1381 

set 

policy-options 

policy-statement 

validation 

term 

invalid 

then 

local- 


1382 

preference 90 








1383 

set 

policy-options 

policy-statement 

validation 

term 

invalid 

then 

validation- 

1384 

state invalid 








1385 

set 

policy-options 

policy-statement 

validation 

term 

invalid 

then 

reject 


1386 

set 

policy-options 

policy-statement 

validation 

term 

unknown 

from 

protocol 

bgp 

1387 

set 

policy-options 

policy-statement 

validation 

term 

unknown 

then 

validation- 

1388 

state unknown 








1389 

set 

policy-options 

policy-statement 

validation 

term 

unknown 

then 

accept 



1390 2.6.9 Router AS 65507 Configuration - Cisco 

1391 Router AS 65507 represents an enterprise edge router for AS 65507. For the lab build, this router 

1392 originates BGP updates from its own AS and receives and sends routes to and from its eBGP peer, AS 

1393 65503. 

1394 hostname AS65507 

1395 ! 

1396 interface Loopbackl 

1397 ip address 10.70.0.1 255.255.0.0 

1398 ipv6 address 7070:7070:7070:7070::1/64 
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1399 

1400 

1401 

1402 

1403 

1404 

1405 

1406 

1407 

1408 

1409 

1410 

1411 

1412 

1413 

1414 

1415 

1416 

1417 

1418 

1419 

1420 

1421 

1422 

1423 

1424 


interface GigabitEthernetO/0 


ip address 10.99.99.22 255.255.255.252 
ipv6 address FD37:F:F:1::7/64 

I 

interface GigabitEthernetO/1 
ip address 172.16.0.1 255.255.0.0 

I 

router bgp 65507 
bgp log-neighbor-changes 
neighbor 10.99.99.21 remote-as 65503 
neighbor FD37:F:F:1::3 remote-as 65503 

I 

address-family ipv4 
redistribute connected 
neighbor 10.99.99.21 activate 
no neighbor FD37:F;F:1: :3 activate 
exit-address-family 

I 

address-family ipv6 
redistribute connected 
neighbor FD37:F;F:1:;3 activate 
exit-address-family 

I 

access-list 23 permit 10.10.10.0 0.0.0.7 
ipv6 router rip prod 
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1425 

1426 

1427 

1428 

1429 

1430 

1431 

1432 

1433 

1434 

1435 

1436 

1437 

1438 

1439 

1440 

1441 

1442 

1443 

1444 

1445 

1446 

1447 

1448 

1449 

1450 


end 


2.6.10 Router AS 65508 Configuration - Cisco 

Router AS 65508 represents a hijacker masquerading as an enterprise edge router. For the lab build, this 
router originates BGP updates for routes that are held by other ASes (i.e., for routes for which it is not 
authorized to originate updates), in order to demonstrate route hijacks. 

hostname AS65508 

I 

ipv6 unicast-routing 

ipv6 cef 

I 

interface Loopbackl 
ip address 10.80.0.1 255.255.0.0 
ipv6 address 8080:8080:8080:8080::1/64 

I 

interface GigabitEthernetO/0 
ip address 10.99.99.30 255.255.255.252 
ipv6 address FDOO:F:F:1::61/64 
ipv6 address FD08:F:F:1::8/64 

I 

interface GigabitEthernetO/1 
ip address 172.16.8.1 255.255.255.0 

I 

router bgp 65508 
bgp log-neighbor-changes 
neighbor 10.99.99.29 remote-as 65500 
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1451 

1452 

1453 

1454 

1455 

1456 

1457 

1458 

1459 

1460 

1461 

1462 

1463 

1464 

1465 

1466 

1467 

1468 

1469 

1470 

1471 

1472 

1473 

1474 

1475 

1476 

1477 


neighbor FD08:F:F:1::10 remote-as 65500 


address-family ipv4 
redistribute connected 
neighbor 10.99.99.29 activate 
no neighbor FD08:F;F:1::10 activate 
exit-address-family 

I 

address-family ipv6 
redistribute connected 
neighbor FDO8:F;F:1::10 activate 
exit-address-family 

I 

ipv6 router rip prod 

I 

end 

2.6.11Cisco lOS XRv Router Configuration 

The Cisco lOS XRv software was also used to perform many of the functional tests, as many ISPs 
currently use it in their network environment. The baseline configuration is provided below. Depending 
on the test case, this router can replace any other router shown in Figure 1-2, in order to properly 
perform the test. 

RP/0/RP0/CPU0:ios#sho run 

!! lOS XR Configuration version = 6.4.1 

I 

interface MgmtEthO/RPO/CPUO/0 
ipv4 address 192.168.1.201 255.255.255.0 
ipv6 address fdOO:f:f:1::201/64 
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1478 

1479 

1480 

1481 

1482 

1483 

1484 

1485 

1486 

1487 

1488 

1489 

1490 

1491 

1492 

1493 

1494 

1495 

1496 

1497 

1498 

1499 

1500 

1501 

1502 

1503 


route-policy pass-all 


pass 

end-policy 

I 

router bgp 65501 

bgp router-id 1.1.1.1 

rpki server 192.168.1.146 
transport tcp port 8282 
refresh-time 15 

I 

address-family ipv4 unicast 
bgp bestpath origin-as allow invalid 

I 

address-family ipv6 unicast 
bgp bestpath origin-as allow invalid 

I 

neighbor 192.168.1.62 
remote-as 65501 
address-family ipv4 unicast 
route-policy pass-all in 
route-policy pass-all out 

I 

I 

neighbor fdOO:f:f:1::62 
remote-as 65501 


NIST SP 1800-14C: Protecting the Integrity of Internet Routing 


57 



1504 address-family ipv6 unicast 

1505 route-policy pass-all in 

1506 route-policy pass-all out 

1507 ! 

1508 ! 

1509 ! 

1510 end 
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1511 Appendix A List of Acronyms 

AFRINIC African Network Information Center 


APNIC 

Asia-Pacific Network Information Center 

ARIN 

American Registry for Internet Numbers 

AS 

Autonomous System 

BGP 

Border Gateway Protocol 

BGPsec 

Border Gateway Protocol Security 

BGP-SRx 

BGP Secure Routing Extension 

BIO 

BGPSEC-IO 

CA 

Certificate Authority 

CPU 

Central Processing Unit 

eBGP 

Exterior Border Gateway Protocol 

Gb 

Gigabyte(s) 

GbE 

Gigabit(s) Ethernet 

GUI 

Graphical User Interface 

iBGP 

Interior Border Gateway Protocol 

IETF 

Internet Engineering Task Force 

lOS 

Internetwork Operating System 

IP 

Internet Protocol 

ISP 

Internet Service Provider 

IT 

Information Technology 

JUNOS 

Juniper Operating System 

LACNIC 

Latin America and Caribbean Network Information Center 

NCCoE 

National Cybersecurity Center of Excellence 

NIST 

National Institute of Standards and Technology 

OS 

Operating System 
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RFC 

Request for Comments 

RIPE NCC 

Reseaux IP Europeens Network Coordination Centre 

RIR 

Regional Internet Registry 

ROA 

Route Origin Authorization 

ROV 

Route Origin Validation 

RPKI 

Resource Public Key Infrastructure 

RRDP 

RPKI Repository Delta Protocol 

RTR 

Router 

SIDR 

Secure Inter-Domain Routing 

SP 

Special Publication 

TAL 

Trust Anchor Locator 

URL 

Uniform Resource Locator 

VLAN 

Virtual Local Area Network 

VM 

Virtual Machine 

VRP 

Validated ROA Payload 

WAN 

Wide Area Network 
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